Replies: 5 comments
-
|
Hello Wolfgang, I'm very happy that someone thinks about appearance like this. I'm not strong in GUI, I'm more professionally focused on back-end programming, GUI development is new to me. See my comments below.
Some of the things you mentioned here are unfortunately issues of the QT framework. I don't know exactly what distribution you use, but Ubuntu 20.04 has QT 5.12 - windows are barely visible here. The situation will change by moving to QT 5.15, which you can look forward to for example Ubuntu 22.04. Just to note: All Windows can be docked inside the Main Application Window or floated as a top-level window on the desktop. (see https://github.com/foldynl/QLog/wiki/Main-Window#additional-windows) Related to the font size, it's my idea that QLog doesn't give a lot of settings for customization. After experience with CQRlog, I do not want to give too much freedom to the user. I would like to have a visual appearance under control. If you give a freedom in the choice of font, font size or styles, it will follow the same path as CQRLog (I had huge problems with my desktop and CQRLog - incorrect font size, short Edit boxes etc). I apologize to Peter (author CQRLog). I know he did a lot of work, I can see it now after 7 months of QLog development but there is a need to keep some things under control. When I return to the main philosophy of QLog. I would like to use modern look, but I would like to keep the number of settings as small as possible. I don't like logs when I can change everything, but the authors didn't think about what this setting could do in the future. Then it leads to fatal mistakes or unwanted side effect or unpredictable behaviour (less = more)
It is a new behavior in QLog 0.5 to have time with seconds. it seemed to me that having a time with seconds would be useful. For example, if you make more QSOs per minute, you are able to see the order over time. I'll think about whether to stay with the seconds or return back when Time was present in format HH:MM. Related to "UTC", it was a little surprised for me. This data is generated by the operating system based on the Locale setting. The behavior is different on Linux, where UTC is added, and Windows, where UTC is not present. Yes, it will be necessary to rework it in the future, but unfortunately now I do not know how to make it look the same on Linux with US, EN, DE or CZ locale and Windows
You are right. It will be change in a next release.
You are right. It will be change in a next release.
I have to admit that the primary development is performed on 4K monitor. But I have a list of tests and one of them is a test of whether everything works on 15inch LCD with a resolution of 1920x1080. Lower resolution is no longer supported 73 de Ladislav |
Beta Was this translation helpful? Give feedback.
-
|
what I forget. Given that you prefer CW and I'm just starting to learn CW, which is now interrupted by the development of QLog. What exactly do you expect from QLog to help you in CW? Do you need for example CW macros? Currently QLog does not contain any support for WinKey or K3NG Arduino CW Keyer. But I plan to implement something like that. Where should I start to implement the most activities that would make your CW operation easier in QLog? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Ladislav, my system is currently Kubuntu 21.10 with "kubuntu-ppa/backports". QT is version 5.15.2. I'm not familiar with GUI programming, as that was always too much work for me for personal use of Python scripts, hi. It is therefore always a bit difficult to understand the problems with the development environments. I can understand that you would like to have the visual appearance under control and also the reduction of the setting options, and I have no problem with that. Working with new software is only really fun if you are prepared to get involved. It doesn't make much sense to keep getting angry about things you can't change yourself. As I said, at the moment I can manage quite well with the current layout. The internal processing of seconds can be left as it is. ADIF allows both formats. The only question is whether this should be shortened to an "HH:MM" format for the display. "UTC" is actually unnecessary because the times are always in UTC and the time zone is already displayed in the "Clock" window. The question of translations must be considered or, if necessary, the column widths must already be taken into account when translating the terms. I don't know how extensive the terms can be in some languages. But everyone can decide for themselves which language they want to use. In this respect, it's not a big problem. CW operation actually only needs minor requirements for me. Since I am not a friend of 599 contests, I do not miss CW macros either. The few macros I use occasionally I programmed in K3 and K2 and use them from there. However, since CQRLog implemented the macros, I occasionally use them on a small scale via the CAT interface. The support for WinKey or K3NG Arduino CW Keyer will be important for many other OM's, so that an implementation already makes sense. As I am a person with low equipment requirements, I am certainly not a good example for CW functions in logbook programs. There it would be necessary to find someone in advance who has higher demands regarding CW, so that these functions could be implemented systematically. I like to use one of my home-made CW transceivers portably or on holiday with an "old style" paper log, which is also a lot of fun. You can see some of them on my website (dl2ki.de). But you should not neglect the CW project too much. Unfortunately, I also started much too late. After all, I have achieved membership of the HSC and have been trying to increase CW speed further for some time. There it would be nice to be a few years younger, hi. Another idea on the side. The "Rig" window could be supplemented with small buttons for direct band switching and for switching between 2 transceivers. (I use here alternately a K3 and a K2 for QRP operation with the same log and different QTH profiles). I will observe the further development of QLog with great interest and am pleased that someone is taking the trouble to develop a new log program. I think you are on the right track. 73, Wolfgang |
Beta Was this translation helpful? Give feedback.
-
|
Hi Ladislav, here are three simple suggestions for the rig window created with GIMP. The third example would probably take the least space if you would display the contents of the menus in the window itself. I'm sure there are other options as well. I am aware that there is a lot of work behind the examples. Especially since there are different concepts to think about in advance. If one supports 2 rigs, it is not said that these are two KW transceivers. Therefore it is possible to introduce "Rig-Profiles", in which not only the Hamlib-data, but for example also the data for the band-selection-buttons / menus are adjustable. With a KW-Trx and a UHF/VHF-Trx then the buttons would be exchanged accordingly with. On the other hand one will find a band switching probably rather with short wave transceivers. I think that you must provide first of all a concept, before one changes there something at the Rig window. With it it should be however first of all good with the pieces of advice. I do not want to keep you from the work , hi. 73, Wolfgang
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for suggestions. Unfortunately, the current internal source code design is not prepared for two rigs. Therefore, your change is not only about Window design, but I have to review/redesign the internal architecture. The change is in my queue of improvements but I'm afraid it won't be a part of the upcoming release. |
Beta Was this translation helpful? Give feedback.
-
Modern logbook programmes present a great deal of information to the user via the surface of the software, which requires a clear presentation, even on smaller screens such as laptops. In some programmes, however, this is prevented by a window design that is too rigid.
The arrangement of the windows on the desktop is also not freely selectable, but is subject to some restrictions.
The "Bandmap" window, for example, requires an arrangement in portrait format so that a required section of the band can be displayed. The "DX Cluster" window requires an arrangement in landscape format in order to display the information lines.
In order to arrange the various windows on the desktop as individually as possible, it makes sense in my view to reduce the data displayed to the required extent. Furthermore, the window geometry should be designed in such a way that there are no unnecessary empty areas.
It could also be that the presentation of a narrow window border improves the overall presentation visually.
Through these steps, a variable font size and a flexible adjustment of the window sizes, it can be achieved that an individual arrangement of the windows on the desktop can take place as optimally as possible.
The arrangement of tabs in the lower area of the QSO window is very good, since the information content can be distributed over several tabs.
Examples:
Column "Time on" ("Time off")
The display of the seconds and the time zone "UTC" can be omitted in my view. Thus, the column width can be reduced by 7 characters.
If the date is moved to a separate column, the date in the "Time off" column can be omitted.
"RST Sent", "RST Rcvd", "QSL Sent", "QSL Rcvd", ...
The columns each contain a few characters of data, but the headings make them unnecessarily wide. In addition, the translation of the column headings in other languages is often longer (in German, at least, this is the case). It would therefore be worth considering whether the column headings should be shortened to the necessary size and generally left in English. Personally, I prefer to use the English version at present.
Example: "RSTs", "RSTr", "QSLs", QSLr", ...In this way, a revision of all headings and column contents could improve the flexibility of the window sizes.
Bandmap window
The "Bandmap" window cannot be displayed narrower. The left margin between the window border and the frequency could be reduced. Furthermore, the length of the lines between the frequency scale and the call signs.This, and an adjustable font size, could improve the flexibility of the window width.
I think it makes sense to first focus on the design of the user interface, as a later adaptation is always associated with additional work.
Personally, however, I have been able to work well with the current design so far, as I have found a practical arrangement of the windows on my 21.5 inch monitor based on the current software version.
My English is not very good, but I hope it is understandable, hi.
73, Wolfgang
DL2KI
Beta Was this translation helpful? Give feedback.
All reactions