Missing flags.qrc

[eliggett]

Hi,

Just did a fresh pull and I am seeing this build error: /usr/lib/qt5/bin/rcc: File does not exist 'res/flags/flags.qrc' Do I need to do something to generate that file, or is it perhaps left out from the repo?

I'd really like to try your logging software. My platform is Linux Mint 20.3 x64.

Thanks,

--E de W6EL

[eliggett]

I found that by removing the line that requests flags.qrc in QLog.pro, I was able to get past this requirement.

I also had to change one more thing to do with hamlib. It looks like the version string you're expecting is a little different with mine than yours.

<command-line>: error: expected ‘)’ before ‘~’ token
../QLog/ui/MainWindow.cpp:632:78: note: in expansion of macro ‘HAMLIBVERSION_MINOR’
  632 |     QString hamlibVersion = QString("%1.%2.%3").arg(HAMLIBVERSION_MAJOR).arg(HAMLIBVERSION_MINOR).arg(HAMLIBVERSION_PATCH);

I just made HAMLIBVERSION_MINOR "x" and it compiled fine.

According to my rigctl that I have installed, this is the version of hamlib that I have:

rigctl Hamlib 4.5~git Sat Aug 13 13:52:42 2022 +0000 SHA=810da5

My guess is your code expects a number but it got 5~git. Maybe you can protect against this. Hamlib really should define non-numbers with quotes...

Anyway, with those two changes, qlog is working and I am able to communicate with it using wfview's built-in rigctld emulation, so all is good so far! Thank you for contributing what seems to be a very nice program.

--E de W6EL

[foldynl]

Hi,

see compilation instruction https://github.com/foldynl/QLog/wiki/Installation#installation-steps---developers

you have to clone the report: git clone --recurse-submodules https://github.com/foldynl/QLog.git (recurse-submodules is must be present).

you are right about hamlib. Compilation assumes that hamlib package is a system package (the version is determined by pkg-config). If it's from repo or not a standard version, then an error occurs. I will try to see how it can be solved. Otherwise, for this case, it is necessary to set HAMLIBVERSION variables in the .pro file.

[eliggett]

Ahh! I should have checked your directions more carefully! Sorry about that! Yes, I often run with libs outside my distro. I think this really is more of a hamlib bug than anything. A version “string” should have quotes. Thank you for the prompt reply, —Ede W6EL On Dec 9, 2022, at 11:59 PM, foldynl @.***> wrote: Hi, see compilation instruction https://github.com/foldynl/QLog/wiki/Installation#installation-steps---developers you have to clone the report: git clone --recurse-submodules https://github.com/foldynl/QLog.git (recurse-submodules is must be present). you are right about hamlib. Compilation assumes that hamlib package is a system package (the version is determined by pkg-config). If it's from repo or not a standard version, then an error occurs. I will try to see how it can be solved. Otherwise, for this case, it is necessary to set HAMLIBVERSION variables in the .pro file.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[foldynl]

Ahh! I should have checked your directions more carefully! Sorry about that!

No problem. Your question can always improve the Wiki. Many thanks for your feedback.

I think this really is more of a hamlib bug than anything.

I do not think that it is a hamlib bug. In general, the QLog is not prepared to have self-compiled Hamlib because I assume the hamlib version is available via pkg-config. Unfortunately, in the case of custom installation, it is not available.I'll have to work on that.

Otherwise, it's a shame that hamlib doesn't have something to identify the version during compilation. Or I don't know about it. I used string inside hamlib, but it wasn't very reliable. The problem is that hamlib changes from version to version, so you need to be careful about which version you are compiling it against. QLog is prepared from Ubuntu 20.04 to 22.04. it means hamlib version range from 3.3 to 4.3. Some versions are buggy so you have to disable some features for them.

I also tested QLog against wfview. It is a nice software but the early versions had an issue to properly simulate rigctl. I also tried it via a virtual port

[foldynl]

Oh...that's faux pas. I knew your name from somewhere, but I couldn't remember where....wfview is your baby !!! I confess that it has been a long time since I tried it. WSJTX had a problem with the wfview's internal rigctld. Otherwise, I have to say that it is a nice project.it has great potential.

[eliggett]

Glad you like wfview! I'm not seeing any rigctl issues between QLog and wfview today except for one somewhat rare "Unimplemented command get_lock_mode", which doesn't seem to impact anything (I saw twice in the last hour). QLog is tracking wfview perfectly, including PTT. There is a bit of delay but that is probably just the polling interval in qlog, which I'd crank up if I see an adjustment for it (I see the adjustment for serial radios but not rigctl).

I see the connection to QRZ is working, maps are good, clusters working, this is a fine program. I don't normally do logging but I may have to start :-).

It's funny, I am always telling people to follow the directions line by line, and here I went cloning QLog without recursive-submodules! Ha! Taste of my own medicine, so to speak.

I am having one issue with qt styles/themes. When I start QLog, it comes up in "bright white" default theme. But none of my other qt apps do this. If I start it with an invalid style, such as "unknown":

./qlog -style unknown
qt5ct: using qt5ct plugin
QApplication: invalid style override passed, ignoring it.
    Available styles: Breeze, cleanlooks, gtk2, cde, motif, plastique, qt5ct-style, Windows, Fusion

Then it actually starts using my system theme. Not sure what that's about. I don't see any environmental variables that would likely throw it off and other qt apps from the same terminal session start with the expected theme. The DE here is Cinnamon. Not a big deal, I can just pass a dumb argument like this from the desktop launcher.

Keep up the great work. Let me know if you ever want to collaborate on anything; our projects seem to use a lot of the same techniques and libraries.

--E de W6EL

[foldynl]

Glad you like wfview! I'm not seeing any rigctl issues between QLog and wfview today except for one somewhat rare "Unimplemented command get_lock_mode", which doesn't seem to impact anything (I saw twice in the last hour).

QLog uses only hamlib functions to connect rigctld. maybe it's something that was added to hamlib over time and is required for rigctl to do.

QLog is tracking wfview perfectly, including PTT. There is a bit of delay but that is probably just the polling interval in qlog, which I'd crank up if I see an adjustment for it (I see the adjustment for serial radios but not rigctl).

poll interval is not implemented, because at the time when I was preparing it, rigctl had a fixed internal pool interval implemented. I haven't checked since then to see if they changed it.

I see the connection to QRZ is working, maps are good, clusters working, this is a fine program. I don't normally do logging but I may have to start :-).

there is still a lot of work here. It endless work, as you know

Then it actually starts using my system theme. Not sure what that's about. I don't see any environmental variables that would likely throw it off and other qt apps from the same terminal session start with the expected theme. The DE here is Cinnamon. Not a big deal, I can just pass a dumb argument like this from the desktop launcher.

I will try to install Linux Mint 20.3 x64 and test it. With Wolfgang (DL2KI) we were looking for another interesting thing. It carried a sound when QLog emits an alarm. And we found out that it is necessary to enable system sounds in the OS. It should be something similar. Try setting environment variable QT_STYLE_OVERRIDE to override the default style.

Keep up the great work. Let me know if you ever want to collaborate on anything; our projects seem to use a lot of the same techniques and libraries.

You are absolutely right. Thank you.

If you feel that something could be improved, let me know. I welcome all feedback.it would be great if both applications could complement each other. Qlog can never be as perfect for displaying rig data as wfview does. QLog is written for a generic rig. On the other hand, your application should not integrate log functionalities, because in my opinion it is an application to CONTROL the rig.

[eliggett]

I do see one environment variable which could be part of this. I believe this variable tells the program to use qt5ct to determine the theme, but I am honestly not sure. With and without this variable set, the result is the same bright-white default qt appearance. It's not a big deal for me since I can override it with that "unknown" style hack. The variable:

QT_QPA_PLATFORMTHEME=qt5ct

Again, it does the same thing either way, so this may just be a minor clue in whatever is going on.

Now, trying the QT_STYLE_OVERRIDE variable, I get the same behavior (default bright white theme). If QT_QPA_PLATFORMTHEME is not set, and QT_STYLE_OVERRIDE is set, then I get a crash on startup (perhaps nobody else will do this though):

me@genesis:/usr/local/share/applications$ export QT_STYLE_OVERRIDE=gtk2
me@genesis:/usr/local/share/applications$ qlog

(qlog:1344833): GLib-GObject-WARNING **: 11:12:14.830: cannot register existing type 'GdkDisplayManager'

(qlog:1344833): GLib-CRITICAL **: 11:12:14.830: g_once_init_leave: assertion 'result != 0' failed

(qlog:1344833): GLib-GObject-CRITICAL **: 11:12:14.830: g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)' failed

(qlog:1344833): GLib-GObject-WARNING **: 11:12:14.830: invalid (NULL) pointer instance

(qlog:1344833): GLib-GObject-CRITICAL **: 11:12:14.830: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(qlog:1344833): GLib-GObject-WARNING **: 11:12:14.830: invalid (NULL) pointer instance

(qlog:1344833): GLib-GObject-CRITICAL **: 11:12:14.830: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(qlog:1344833): GLib-GObject-WARNING **: 11:12:14.832: cannot register existing type 'GdkDisplay'

(qlog:1344833): GLib-CRITICAL **: 11:12:14.832: g_once_init_leave: assertion 'result != 0' failed

(qlog:1344833): GLib-GObject-CRITICAL **: 11:12:14.832: g_type_register_static: assertion 'parent_type > 0' failed

(qlog:1344833): GLib-CRITICAL **: 11:12:14.832: g_once_init_leave: assertion 'result != 0' failed

(qlog:1344833): GLib-GObject-CRITICAL **: 11:12:14.832: g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)' failed
Segmentation fault (core dumped)

Yes, endless work, indeed.

wfview is definitely in the radio control category. It has a long way to go, and we are probably going to have to re-work a lot of the radio control code in order to move it forward with more advanced features. I'm thinking of using a QMap and some loadable plaintext files to set radio personalities and features, so that the rest of wfview is abstracted from exactly how the commands are formed. But that has been difficult to do and we'll have to gut thousands of lines to get it working. We added dx clusters recently. I was hesitant since it's kind of outside the "control" category, but when you see them on the waterfall it is actually pretty nice.

It is smart to not write much (or any) rig-specific code into QLog. Keep it pure. It's very nice the way it is right now. Once you jump into direct radio interfaces it's a mess! hamlib, for all its faults, has a very large number of supported radios (and other things), plus the TCP/IP rigctl interface which is catching on in many other programs (such as gpredict).

--E de W6EL

[foldynl]

I installed Mint in a VM and made a few tests. I finally understood your problem.

I already had a discussion about using the style - Issue #88

It is necessary to mention these things here.

1) QLog is fully tuned to Fusion style. If style is not passed as an application input parameter (--style), then Fusion is forced used 2) Input parameter style was added only as an experiment. As it was mentioned in #88, some of the styles are broken. It's a style problem on the one hand, and it can also be a QLog problem on the other. I confess, I design and test everything against Fusion. I am not able to test QLog on different styles and guarantee that everything will work. 3) If you want to use default system style it is necessary to run QLog like this

./qlog --style=qt5ct-style

more about QLog's styles https://github.com/foldynl/QLog/wiki/Main-Window#qt-style-and-dark-mode

4) Qlog can be switched directly in the application to Dark Mode in Fusion style - right bottom corner. This icon is only visible if QLog runs WITHOUT the --style parameter

I know it's a limitation, but I'm not QT specialist and I may not be familiar with styles. For example, I have no idea why when I activate GTK2 some icons are OK, some are broken even if they are all implemented the same way.

As I wrote, there is still space for improvement.

[foldynl]

I am still testing and I cannot explain this. Maybe you've met this and can figure out where I'm doing wrong

The first figure is QLog with GTK2 style, the second one is Qlog with Fusion. The icons Save and Reset use default theme Icon "Document-Save" and "Document-reset". I can understand that the definition of the given icons does not have to be defined in the style, but please why do these icons break the button in this way?

The third unfunctional icon "QRZ" has a "Custom" icon. It can be caused by the appropriate selection of the icon (wrong format, size etc.). However, there is still a big issue with mentioned system icons.

On the other hand CDE style is correct.

Therefore I chose one reference style - Fusion and implemented a possibility to switch it to the dark mode.