ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
esc to dismiss
Hi Mike,
you already reported something similar a few months ago. /g/qlog/message/472 So it's not a new behavior but just a change in behavior that may be caused by a hamlib upgrade.
see details below.
Especially the last link shows that there is no solution for it now.
pá 17. 1. 2025 v?3:23 odesílatel Mike - K3SNO, #707 via <mcguire2003= [email protected]> napsal:
Since the update to 0.41.0 I'm having a strange issue. Nothing was
changed other than the update and now my FTDX10 does not change band and
frequency correctly. When clicking on a spot and going from 40/80m LSB
to 10-20m USB, the frequency changes correctly (at first) but the mode
does not change correctly. The third double-click causes the mode to
change correctly but the frequency Is NOW offset by the USB/LSB
difference. Then the third double-click puts the frequency right. It
does this in both directions.
Can anyone point me in a direction of assistance?
Linux Mint 21.3
QLog 0.41.0 w/ hamLib 4.6
--
V/R,
Michael G. Mcguire, K3SNO
484-703-9591
So Mote It Be
|
Since the update to 0.41.0 I'm having a strange issue. Nothing was changed other than the update and now my FTDX10 does not change band and frequency correctly. When clicking on a spot and going from 40/80m LSB to 10-20m USB, the frequency changes correctly (at first) but the mode does not change correctly. The third double-click causes the mode to change correctly but the frequency Is NOW offset by the USB/LSB difference. Then the third double-click puts the frequency right. It does this in both directions.
Can anyone point me in a direction of assistance?
Linux Mint 21.3
QLog 0.41.0 w/ hamLib 4.6
--
V/R,
Michael G. Mcguire, K3SNO
484-703-9591
So Mote It Be
|
Also, based on your postscript we are probably not setting the flags correctly on app open versus showing the sub-windows after the app is open.
Cheers
Kyle
|
Seems like this is an occurance of this issue: .
In macos QT, floating windows are considered utility windows which have the behaviour your video demonstrates. I tried to address this behaviour in 530 by setting flags to disable the hiding. I'll try to do more testing on this. At the time of the commit it seemed to work for floating windows that only had 1 panel.
Kyle
|
Michael good morning,
sorry for the delay, but I couldn't answer before.
Today I find myself in the same situation that I had before the update to 0.41.
Surely between the first email and today I had some updates of various apps.
To be safe I stopped the various apps that start in the background except "dropbox" which is essential for the use of the programs as I have all symbolic links to the data placed in the cloud, I ran qlog by itself, the result is that by clicking on any part of the screen all the icons that I opened disappear.
You can see the behavior in the short video that I attach.
I am a retired computer scientist, if you think I can be of help to you in my small skills I am available.
73 Roberto IU2NUB
?
PS. After further testing I discovered that if I close the app without closing the windows it behaves as per the video, if I open the app and then open the windows it seems that these do not disappear if I bring the focus on other windows
?
|
I'm not sure I am following what the problem is.? Can you walk me through what you are doing so I can reproduce it? As well as what you expect to happen?
Thanks
MIchael, ?AA5SH
On Sun, Jan 12, 2025 at 4:19?AM Roberto IU2NUB via <iu2nub.rb= [email protected]> wrote: Thanks Michael great job,
I opened all the windows and I'm really sorry to have to tell you that there are two commands left on the keyboard for the "clock" and "radio" windows.
My system is: macbook pro 16"
m1 Max, 64gb Sequoia 15.2
If I can give you more info let me know
Thanks again
73 Roberto IU2NUB
|
Re: Interesting behavior with 0.41.0
|
Re: Interesting behavior with 0.41.0
You have installed TQSL because you chose to install the Flatpak version
From the README file: Flatpak package is available via . The package contains built-in TrustedQSL.
Windows and Linux DEB/RPM packages do not contain the TQSL.
Regards Ladislav
Fresh install of Linux Mint 21.2 Victoria. All updates installed.
Installed QLog 0.41.0 (Linux Flatpak)
No issues. ? Runs great.?
However when I execute the program a TQSL icon is placed on my task bar. I have not installed TQSL.
Did not do this with previous versions.
?
I also did a fresh Win 10 install on a second hard drive, and installed the Windows ver of?
QLog 0.41.0. Does not place this TQSL icon when running the Windows version.
?
?
Clues?
?
73,? WW4DX
?
|
Interesting behavior with 0.41.0
Fresh install of Linux Mint 21.2 Victoria. All updates installed.
Installed QLog 0.41.0 (Linux Flatpak)
No issues. ? Runs great.?
However when I execute the program a TQSL icon is placed on my task bar. I have not installed TQSL.
Did not do this with previous versions.
?
I also did a fresh Win 10 install on a second hard drive, and installed the Windows ver of?
QLog 0.41.0. Does not place this TQSL icon when running the Windows version.
?
?
Clues?
?
73,? WW4DX
?
|
Thanks Michael great job,
I opened all the windows and I'm really sorry to have to tell you that there are two commands left on the keyboard for the "clock" and "radio" windows.
My system is: macbook pro 16"
m1 Max, 64gb Sequoia 15.2
If I can give you more info let me know
Thanks again
73 Roberto IU2NUB
|
Re: Feature request: Clock setting toggle. (take a moment, hear me out)
I fully understand and support this request. Just my two cents.
--
___
Slav, EI6KW, SP3RXO
|
Got it Ladislav!? Adding my comments in your comments??...
- had to redownload all the source.? git pull command didnt worked.
I don't know how you did it, but I'm sure that git pull must definitely work. When
I create a release, I use 4 independent Virtual Machines where git pull
is called during the build process. Everything went as expected today.
Unfortunately, you did not mention where the issue was.
So I have all my source codes in ~/.sources/QLog.? what I did was:
cd ~/.sources/QLog git pull
PREFIX=/opt/qlog qmake QLog.pro make? sudo make install I gave me an error but I didnt took note of it unfortunately (this was before my morning coffee ?).? But definitely will keep this email saved and try again on next release, as that is the way I want to do it. ------------------------------------------------------
- for
some reason had to download hamlib 4.5.? QLog didnt liked the latest
hamlib.? Tried compiling several times, even downloading manually
instead of git command, but didnt worked.? It worked fine with rigctl
version 4.5.5.
QLog can use Hamlib 4.6. Windows and
Flatpak packages include version 4.6. It is necessary to have the
'includes' and 'libs' settings configured properly. Ensure that your
compiler does not use header files from the system's Hamlib
installation, which is typically version 4.5.5.
After reading your replied, I looked and seems that there was some hamlib files left from previous installation under /usr/include/hamlib.? I guess that the software was trying to use the new installed version on /opt/hamlib/ with the old includes on /usr... just guessing.? I delete the old /usr/include/hamlib,? Uninstalled hamlib 4.5, and installed 4.6 and it worked.
-----------------------------------------------------
- had to download manually the flags folder, when downloaded the flags folder was empty.
README file contains a solution for this. QLog repo contains a flag module. Therefore you have to download git report: git clone --recurse-submodules
Thanks for pointing this one to my attention, I missed that one.? added to my notes.
-----------------------------------------------------
Again, thanks for another great version of this awesome software!
Let me add my comments:
- had to redownload all the source.? git pull command didnt worked.
I don't know how you did it, but I'm sure that git pull must definitely work. When I create a release, I use 4 independent Virtual Machines where git pull is called during the build process. Everything went as expected today. Unfortunately, you did not mention where the issue was.
- for
some reason had to download hamlib 4.5.? QLog didnt liked the latest
hamlib.? Tried compiling several times, even downloading manually
instead of git command, but didnt worked.? It worked fine with rigctl
version 4.5.5.
QLog can use Hamlib 4.6. Windows and Flatpak packages include version 4.6. It is necessary to have the 'includes' and 'libs' settings configured properly. Ensure that your compiler does not use header files from the system's Hamlib installation, which is typically version 4.5.5. - had to download manually the flags folder, when downloaded the flags folder was empty.
README file contains a solution for this. QLog repo contains a flag module. Therefore you have to download git report: git clone --recurse-submodules
so 11. 1. 2025 v?18:44 odesílatel Joel Vazquez, WE0DX via <ae4sr.radioop= [email protected]> napsal: Thanks for another great release!!!
Just some notes:? - had to redownload all the source.? git pull command didnt worked.
- for some reason had to download hamlib 4.5.? QLog didnt liked the latest hamlib.? Tried compiling several times, even downloading manually instead of git command, but didnt worked.? It worked fine with rigctl version 4.5.5.
- had to download manually the flags folder, when downloaded the flags folder was empty.
Other than that, so far so good...
Thank you Michael.
so 11. 1. 2025 v?15:09 odesílatel Michael Morgan via <cmorgan13= [email protected]> napsal: I’ve uploaded the MacOS build:
|
Let me inform you that a new QLog release v0.41.0 is finished.
Changelog:
- [NEW] - Logbook - Added a new context menu item - Update QSO from Callbook (issue #450 @aa5sh)
- [NEW] - DIGI mode is used in case of DXC Digi Spots (issue #480)
- [NEW] - DXC - Retrieve information about SOTA, POTA, IOTA and WWFF from comment (issue #482)
- [NEW] - Alert - Added SOTA, POTA, IOTA and WWFF filter
- [NEW] - Added the COM Port Completer for Windows platform (issue #490)
- [NEW] - Settings - Added DXCC Confirmed By options (issue #508)
- [NEW] - Added POTA Export Formatter (activator/hunter) (PR #514 @kyleboyle)
- [NEW] - CW Console - CW Halt with the user-defined shortcut (issue #518)
- [NEW] - Added an input parameter to save debug message to file
- [NEW] - Logbook - Added sorting function to logbook table columns (PR #540 @kyleboyle)
- [NEW] - Network Notification - Added Rig Status Notification
- [NEW] - Implemented ADIF 3.1.5
- [NEW] - ADIF 3.1.5 - Added new submodes FSKH245 and FSKH105 for HELL
- [NEW] - ADIF 3.1.5 - Added new contest IDs
- [NEW] - ADIF 3.1.5 - Added new columns (Import/Export only)
- [NEW] - ADIF 3.1.5 - Added My DARC DOK to Station Profile
- [CHANGED] - Settings: disabled band and mode name modification
- [CHANGED] - DX Stats contain all enabled bands (issue #538)
- [CHANGED] - Removed Freq, TimeDate On/Off Data Type Indicators (issue #552)
- [CHANGED] - ADIF 3.1.5 - VUCC and MY_VUCC can contain 6 or 4-chars locators
- [CHANGED] - Stop exporting default value N for qsl_rcvd, qsl_sent, lotw/dcl/eslq_qsl_rcvd/sent
- [CHANGED] - Extended QSL/Import Dupe matching rule to Callsign, Band, Mode, Time and Sat_Name (issue #563)
- Fixed MacOS - keep floating windows visible on app unfocus (issue #530)
- Fixed Contest Filter ignores the first QSO (issue #529)
- Fixed It is not possible to quit Qlog with detached widgets Rot & Rig (issue #534)
- Fixed ADX/CSV/JSON do not export non-ASCII chars (issue #542)
- Fixed Checking the 60m checkbox in cluster filters allows 160m spots to appear (issue #543 @aa5sh)
- Fixed Problems uploading to QRZ.com (issue #559 PR #561 @aa5sh)
- Fixed DX Stat screen is jumping up/down
- Fixed Omnirig drivers: Digi modes are not correctly recognized
HAMLIB Upgrade
- Windows and Flatpak packages now include Hamlib v4.6.
Changelog:
Wiki Changelog:
Re: Feature request: Clock setting toggle. (take a moment, hear me out)
I'm not the original requester, but I will give you my reasoning. I
have always used UTC time for any of my amateur radio operations.
That is the way I was taught to do it over 40 years ago. I don't,
however, live my life by UTC time. I hope this makes sense to you.
Thanks for a great logging program, and for working to continuously
improve it.
Roy KW4G
Sebring, Florida
On 1/11/25 2:31 PM, ok1mlg via
groups.io wrote:
toggle quoted message
Show quoted text
OK. Flexibility is a good thing but excessive
flexibility is counterproductive. The average user isn't capable
of foreseeing all the things they could break with various
settings. I'm not talking about time format settings
specifically here, but more generally about the ability to
configure everything in the applications.
But you didn't answer my question. Why do you require a
24-hour format specifically in the ham application, when you
use a 12-hour format for everything else? I'm not criticizing
you; I'm just very curious because it could guide my future
steps.
so 11. 1. 2025 v?18:48
odesílatel Kevin Loughin via <loughkb= [email protected]>
napsal:
What
I have learned in dealing with the larger audience, and also
through my working career in computer support in large
companies, is that everybody has their own preferences. There
is no one "right" way to do anything with a few exceptions.?
You want all of your applications to behave the same with
this regard.? Myself, I would like most of my other
applications to operate on local 12 hour time. But my ham
radio applications to operate on UTC time. I suspect, from
my interactions with others, that this is perhaps the more
common scenario.?
In either case, flexibility within the application merely
broadens its appeal and increases its level of comfort
across the broader audience. Giving the user the choice,
improves the acceptance and appreciation of the program.?
That's my two cents worth.?
Kevin?
On Sat, Jan 11, 2025 at 9:43 AM, ok1mlg via
Please explain
this to me. My
approach is that I want all applications
to be "unified". This
means that if I want a 24h time-format, I
want to see it in all my installed
applications. Why
is your approach that you want to see
applications in 12h-format, but QLog in
24h?
To be honest, the
change is trivial in QLog. We
are talking more about it here than it
would mean to change it. For
me, it is more important to
understand this difference.
After all, this problem is not
only about the 12/24 format, but about the
whole date/time formatting.
pá 10. 1. 2025 v?20:11 odesílatel
Michael Morgan via
<cmorgan13= [email protected]>
napsal:
I agree that is one the few
things that is awkward with the app for me.? I
would like for the app to show 24 hour UTC
time everywhere - log entries, clock etc. ?but
I don't really?want my whole mac showing 24
hour time, guess I'm just to lazy to have to
math the times since I use it not only for ham
tasks.? I've been trying to work out a
script?to launch different things (rigctld so
I can share my radio with QLog and other apps,
do commands so WSJT laucnhes happy and also my
steppir/amp controller apps, etc.) So I could
technically put the LC command in there but
since last step currently is to launch rigctld
since it holds the terminal I wouldn't be able
to then launch QLog so it would take the LC
command.? I'm sure there maybe a way in
applescript to launch it or launch multiple
?terminals or something.? Got to figure that
out.
On Fri, Jan 10, 2025 at
10:09?AM Kevin Loughin via
<loughkb= [email protected]>
wrote:
I am a youtube presenter that does
mostly ham radio videos.? As such, through
comments on my videos, I have a good
impression of the general audience
technical abilities.
?
That said,? I recently reviewed Qlog,?
my new favorite logging software and I
love it.? The perfect balance between
features and simplicity.
?
In my recent post about the clock and
24 hour time, one response pointed me to
the wiki tip about setting an LC system
variable to get the program to display 24
hour time.? Thank you, that solved MY
problem.? However, I can state with
confidence that the majority of the
potential user base for this program are
not at the skill level or competency
required to be digging around in system
configuration files and setting system
variables.
?
So, I would like to request a simple
preference setting,? a toggle between
local and UTC time.? In local mode, the
clock would behave as it does now, basing
it's display on the local system
settings.? In UTC mode, the clock would
display 24 hour time and align it's offset
to UTC.??
This could either be a setting in the
preferences panel, or, ideally, a widget
within the clock panel itself, allowing
the user to toggle the time format as
needed depending on their operating
environment at the time.
?
This would enhance the intuitiveness of
the interface with regard to the clock
display, and work for the entire potential
user base.
?
Thanks for any consideration,
Kevin - KB9RLW
|
Re: Feature request: Clock setting toggle. (take a moment, hear me out)
Oh I totally get that, you don't want to make a program so flexible that they can break it 10 different ways.? I'm mostly am concerned with 24-hour time when it comes to logging. Specifically.? So having my computer on local 12 hour time means I don't have to worry about my calendar sending me a notification about a pending appointment at the wrong time.? But I want my logging program if it's going to automatically enter the time, be synchronized to UTC and 24-hour time.? Previously I used x log or paper logs, so I entered the time manually. Not relying on the computers clock. I have a 24-hour clock on my icom radio and I would just refer to that.? But with something like Q log where it's going to enter the time for me, I definitely want it to be 24-hour time and synchronized to UTC.?
On Sat, Jan 11, 2025 at 12:38 PM, Michael Morgan via groups.io <cmorgan13@...> wrote: I know for me it is I use my laptop for both Ham and work/personal.? I just prefer for my normal life just to be 12 hour.? But for ham everything is typically?in 24hr, QSL, contests etc.? So it is just an ease of use thing. OK. Flexibility is a good thing but excessive flexibility is counterproductive. The average user isn't capable of foreseeing all the things they could break with various settings. I'm not talking about time format settings specifically here, but more generally about the ability to configure everything in the applications. But you didn't answer my question. Why do you require a 24-hour format specifically in the ham application, when you use a 12-hour format for everything else? I'm not criticizing you; I'm just very curious because it could guide my future steps.
so 11. 1. 2025 v?18:48 odesílatel Kevin Loughin via <loughkb= [email protected]> napsal: What I have learned in dealing with the larger audience, and also through my working career in computer support in large companies, is that everybody has their own preferences. There is no one "right" way to do anything with a few exceptions.?
You want all of your applications to behave the same with this regard.? Myself, I would like most of my other applications to operate on local 12 hour time. But my ham radio applications to operate on UTC time. I suspect, from my interactions with others, that this is perhaps the more common scenario.?
In either case, flexibility within the application merely broadens its appeal and increases its level of comfort across the broader audience. Giving the user the choice, improves the acceptance and appreciation of the program.?
That's my two cents worth.? Kevin? On Sat, Jan 11, 2025 at 9:43 AM, ok1mlg via Please explain this to me. My approach is that I want all applications to be "unified". This means that if I want a 24h time-format, I want to see it in all my installed applications. Why is your approach that you want to see applications in 12h-format, but QLog in 24h?
To be honest, the change is trivial in QLog. We are talking more about it here than it would mean to change it. For me, it is more important to understand this difference. After all, this problem is not only about the 12/24 format, but about the whole date/time formatting. pá 10. 1. 2025 v?20:11 odesílatel Michael Morgan via <cmorgan13= [email protected]> napsal: I agree that is one the few things that is awkward with the app for me.? I would like for the app to show 24 hour UTC time everywhere - log entries, clock etc. ?but I don't really?want my whole mac showing 24 hour time, guess I'm just to lazy to have to math the times since I use it not only for ham tasks.? I've been trying to work out a script?to launch different things (rigctld so I can share my radio with QLog and other apps, do commands so WSJT laucnhes happy and also my steppir/amp controller apps, etc.) So I could technically put the LC command in there but since last step currently is to launch rigctld since it holds the terminal I wouldn't be able to then launch QLog so it would take the LC command.? I'm sure there maybe a way in applescript to launch it or launch multiple ?terminals or something.? Got to figure that out.
On Fri, Jan 10, 2025 at 10:09?AM Kevin Loughin via <loughkb= [email protected]> wrote: I am a youtube presenter that does mostly ham radio videos.? As such, through comments on my videos, I have a good impression of the general audience technical abilities.
?
That said,? I recently reviewed Qlog,? my new favorite logging software and I love it.? The perfect balance between features and simplicity.
?
In my recent post about the clock and 24 hour time, one response pointed me to the wiki tip about setting an LC system variable to get the program to display 24 hour time.? Thank you, that solved MY problem.? However, I can state with confidence that the majority of the potential user base for this program are not at the skill level or competency required to be digging around in system configuration files and setting system variables.
?
So, I would like to request a simple preference setting,? a toggle between local and UTC time.? In local mode, the clock would behave as it does now, basing it's display on the local system settings.? In UTC mode, the clock would display 24 hour time and align it's offset to UTC.??
This could either be a setting in the preferences panel, or, ideally, a widget within the clock panel itself, allowing the user to toggle the time format as needed depending on their operating environment at the time.
?
This would enhance the intuitiveness of the interface with regard to the clock display, and work for the entire potential user base.
?
Thanks for any consideration,
Kevin - KB9RLW
|
Great release, Thanks Ladislav!
|
Re: Feature request: Clock setting toggle. (take a moment, hear me out)
I know for me it is I use my laptop for both Ham and work/personal.? I just prefer for my normal life just to be 12 hour.? But for ham everything is typically?in 24hr, QSL, contests etc.? So it is just an ease of use thing.
OK. Flexibility is a good thing but excessive flexibility is counterproductive. The average user isn't capable of foreseeing all the things they could break with various settings. I'm not talking about time format settings specifically here, but more generally about the ability to configure everything in the applications. But you didn't answer my question. Why do you require a 24-hour format specifically in the ham application, when you use a 12-hour format for everything else? I'm not criticizing you; I'm just very curious because it could guide my future steps.
so 11. 1. 2025 v?18:48 odesílatel Kevin Loughin via <loughkb= [email protected]> napsal: What I have learned in dealing with the larger audience, and also through my working career in computer support in large companies, is that everybody has their own preferences. There is no one "right" way to do anything with a few exceptions.?
You want all of your applications to behave the same with this regard.? Myself, I would like most of my other applications to operate on local 12 hour time. But my ham radio applications to operate on UTC time. I suspect, from my interactions with others, that this is perhaps the more common scenario.?
In either case, flexibility within the application merely broadens its appeal and increases its level of comfort across the broader audience. Giving the user the choice, improves the acceptance and appreciation of the program.?
That's my two cents worth.? Kevin? On Sat, Jan 11, 2025 at 9:43 AM, ok1mlg via Please explain this to me. My approach is that I want all applications to be "unified". This means that if I want a 24h time-format, I want to see it in all my installed applications. Why is your approach that you want to see applications in 12h-format, but QLog in 24h?
To be honest, the change is trivial in QLog. We are talking more about it here than it would mean to change it. For me, it is more important to understand this difference. After all, this problem is not only about the 12/24 format, but about the whole date/time formatting. pá 10. 1. 2025 v?20:11 odesílatel Michael Morgan via <cmorgan13= [email protected]> napsal: I agree that is one the few things that is awkward with the app for me.? I would like for the app to show 24 hour UTC time everywhere - log entries, clock etc. ?but I don't really?want my whole mac showing 24 hour time, guess I'm just to lazy to have to math the times since I use it not only for ham tasks.? I've been trying to work out a script?to launch different things (rigctld so I can share my radio with QLog and other apps, do commands so WSJT laucnhes happy and also my steppir/amp controller apps, etc.) So I could technically put the LC command in there but since last step currently is to launch rigctld since it holds the terminal I wouldn't be able to then launch QLog so it would take the LC command.? I'm sure there maybe a way in applescript to launch it or launch multiple ?terminals or something.? Got to figure that out.
On Fri, Jan 10, 2025 at 10:09?AM Kevin Loughin via <loughkb= [email protected]> wrote: I am a youtube presenter that does mostly ham radio videos.? As such, through comments on my videos, I have a good impression of the general audience technical abilities.
?
That said,? I recently reviewed Qlog,? my new favorite logging software and I love it.? The perfect balance between features and simplicity.
?
In my recent post about the clock and 24 hour time, one response pointed me to the wiki tip about setting an LC system variable to get the program to display 24 hour time.? Thank you, that solved MY problem.? However, I can state with confidence that the majority of the potential user base for this program are not at the skill level or competency required to be digging around in system configuration files and setting system variables.
?
So, I would like to request a simple preference setting,? a toggle between local and UTC time.? In local mode, the clock would behave as it does now, basing it's display on the local system settings.? In UTC mode, the clock would display 24 hour time and align it's offset to UTC.??
This could either be a setting in the preferences panel, or, ideally, a widget within the clock panel itself, allowing the user to toggle the time format as needed depending on their operating environment at the time.
?
This would enhance the intuitiveness of the interface with regard to the clock display, and work for the entire potential user base.
?
Thanks for any consideration,
Kevin - KB9RLW
|
Re: Feature request: Clock setting toggle. (take a moment, hear me out)
OK. Flexibility is a good thing but excessive flexibility is counterproductive. The average user isn't capable of foreseeing all the things they could break with various settings. I'm not talking about time format settings specifically here, but more generally about the ability to configure everything in the applications. But you didn't answer my question. Why do you require a 24-hour format specifically in the ham application, when you use a 12-hour format for everything else? I'm not criticizing you; I'm just very curious because it could guide my future steps. so 11. 1. 2025 v?18:48 odesílatel Kevin Loughin via <loughkb= [email protected]> napsal:
What I have learned in dealing with the larger audience, and also through my working career in computer support in large companies, is that everybody has their own preferences. There is no one "right" way to do anything with a few exceptions.?
You want all of your applications to behave the same with this regard.? Myself, I would like most of my other applications to operate on local 12 hour time. But my ham radio applications to operate on UTC time. I suspect, from my interactions with others, that this is perhaps the more common scenario.?
In either case, flexibility within the application merely broadens its appeal and increases its level of comfort across the broader audience. Giving the user the choice, improves the acceptance and appreciation of the program.?
That's my two cents worth.? Kevin? On Sat, Jan 11, 2025 at 9:43 AM, ok1mlg via Please explain this to me. My approach is that I want all applications to be "unified". This means that if I want a 24h time-format, I want to see it in all my installed applications. Why is your approach that you want to see applications in 12h-format, but QLog in 24h?
To be honest, the change is trivial in QLog. We are talking more about it here than it would mean to change it. For me, it is more important to understand this difference. After all, this problem is not only about the 12/24 format, but about the whole date/time formatting. pá 10. 1. 2025 v?20:11 odesílatel Michael Morgan via <cmorgan13= [email protected]> napsal: I agree that is one the few things that is awkward with the app for me.? I would like for the app to show 24 hour UTC time everywhere - log entries, clock etc. ?but I don't really?want my whole mac showing 24 hour time, guess I'm just to lazy to have to math the times since I use it not only for ham tasks.? I've been trying to work out a script?to launch different things (rigctld so I can share my radio with QLog and other apps, do commands so WSJT laucnhes happy and also my steppir/amp controller apps, etc.) So I could technically put the LC command in there but since last step currently is to launch rigctld since it holds the terminal I wouldn't be able to then launch QLog so it would take the LC command.? I'm sure there maybe a way in applescript to launch it or launch multiple ?terminals or something.? Got to figure that out.
On Fri, Jan 10, 2025 at 10:09?AM Kevin Loughin via <loughkb= [email protected]> wrote: I am a youtube presenter that does mostly ham radio videos.? As such, through comments on my videos, I have a good impression of the general audience technical abilities.
?
That said,? I recently reviewed Qlog,? my new favorite logging software and I love it.? The perfect balance between features and simplicity.
?
In my recent post about the clock and 24 hour time, one response pointed me to the wiki tip about setting an LC system variable to get the program to display 24 hour time.? Thank you, that solved MY problem.? However, I can state with confidence that the majority of the potential user base for this program are not at the skill level or competency required to be digging around in system configuration files and setting system variables.
?
So, I would like to request a simple preference setting,? a toggle between local and UTC time.? In local mode, the clock would behave as it does now, basing it's display on the local system settings.? In UTC mode, the clock would display 24 hour time and align it's offset to UTC.??
This could either be a setting in the preferences panel, or, ideally, a widget within the clock panel itself, allowing the user to toggle the time format as needed depending on their operating environment at the time.
?
This would enhance the intuitiveness of the interface with regard to the clock display, and work for the entire potential user base.
?
Thanks for any consideration,
Kevin - KB9RLW
|
Let me add my comments:
- had to redownload all the source.? git pull command didnt worked.
I don't know how you did it, but I'm sure that git pull must definitely work. When I create a release, I use 4 independent Virtual Machines where git pull is called during the build process. Everything went as expected today. Unfortunately, you did not mention where the issue was.
- for
some reason had to download hamlib 4.5.? QLog didnt liked the latest
hamlib.? Tried compiling several times, even downloading manually
instead of git command, but didnt worked.? It worked fine with rigctl
version 4.5.5.
QLog can use Hamlib 4.6. Windows and Flatpak packages include version 4.6. It is necessary to have the 'includes' and 'libs' settings configured properly. Ensure that your compiler does not use header files from the system's Hamlib installation, which is typically version 4.5.5. - had to download manually the flags folder, when downloaded the flags folder was empty.
README file contains a solution for this. QLog repo contains a flag module. Therefore you have to download git report: git clone --recurse-submodules
so 11. 1. 2025 v?18:44 odesílatel Joel Vazquez, WE0DX via <ae4sr.radioop= [email protected]> napsal:
Thanks for another great release!!!
Just some notes:? - had to redownload all the source.? git pull command didnt worked.
- for some reason had to download hamlib 4.5.? QLog didnt liked the latest hamlib.? Tried compiling several times, even downloading manually instead of git command, but didnt worked.? It worked fine with rigctl version 4.5.5.
- had to download manually the flags folder, when downloaded the flags folder was empty.
Other than that, so far so good...
Thank you Michael.
so 11. 1. 2025 v?15:09 odesílatel Michael Morgan via <cmorgan13= [email protected]> napsal: I’ve uploaded the MacOS build:
|
Let me inform you that a new QLog release v0.41.0 is finished.
Changelog:
- [NEW] - Logbook - Added a new context menu item - Update QSO from Callbook (issue #450 @aa5sh)
- [NEW] - DIGI mode is used in case of DXC Digi Spots (issue #480)
- [NEW] - DXC - Retrieve information about SOTA, POTA, IOTA and WWFF from comment (issue #482)
- [NEW] - Alert - Added SOTA, POTA, IOTA and WWFF filter
- [NEW] - Added the COM Port Completer for Windows platform (issue #490)
- [NEW] - Settings - Added DXCC Confirmed By options (issue #508)
- [NEW] - Added POTA Export Formatter (activator/hunter) (PR #514 @kyleboyle)
- [NEW] - CW Console - CW Halt with the user-defined shortcut (issue #518)
- [NEW] - Added an input parameter to save debug message to file
- [NEW] - Logbook - Added sorting function to logbook table columns (PR #540 @kyleboyle)
- [NEW] - Network Notification - Added Rig Status Notification
- [NEW] - Implemented ADIF 3.1.5
- [NEW] - ADIF 3.1.5 - Added new submodes FSKH245 and FSKH105 for HELL
- [NEW] - ADIF 3.1.5 - Added new contest IDs
- [NEW] - ADIF 3.1.5 - Added new columns (Import/Export only)
- [NEW] - ADIF 3.1.5 - Added My DARC DOK to Station Profile
- [CHANGED] - Settings: disabled band and mode name modification
- [CHANGED] - DX Stats contain all enabled bands (issue #538)
- [CHANGED] - Removed Freq, TimeDate On/Off Data Type Indicators (issue #552)
- [CHANGED] - ADIF 3.1.5 - VUCC and MY_VUCC can contain 6 or 4-chars locators
- [CHANGED] - Stop exporting default value N for qsl_rcvd, qsl_sent, lotw/dcl/eslq_qsl_rcvd/sent
- [CHANGED] - Extended QSL/Import Dupe matching rule to Callsign, Band, Mode, Time and Sat_Name (issue #563)
- Fixed MacOS - keep floating windows visible on app unfocus (issue #530)
- Fixed Contest Filter ignores the first QSO (issue #529)
- Fixed It is not possible to quit Qlog with detached widgets Rot & Rig (issue #534)
- Fixed ADX/CSV/JSON do not export non-ASCII chars (issue #542)
- Fixed Checking the 60m checkbox in cluster filters allows 160m spots to appear (issue #543 @aa5sh)
- Fixed Problems uploading to QRZ.com (issue #559 PR #561 @aa5sh)
- Fixed DX Stat screen is jumping up/down
- Fixed Omnirig drivers: Digi modes are not correctly recognized
HAMLIB Upgrade
- Windows and Flatpak packages now include Hamlib v4.6.
Changelog:
Wiki Changelog:
Re: Feature request: Clock setting toggle. (take a moment, hear me out)
What I have learned in dealing with the larger audience, and also through my working career in computer support in large companies, is that everybody has their own preferences. There is no one "right" way to do anything with a few exceptions.?
You want all of your applications to behave the same with this regard.? Myself, I would like most of my other applications to operate on local 12 hour time. But my ham radio applications to operate on UTC time. I suspect, from my interactions with others, that this is perhaps the more common scenario.?
In either case, flexibility within the application merely broadens its appeal and increases its level of comfort across the broader audience. Giving the user the choice, improves the acceptance and appreciation of the program.?
That's my two cents worth.?
On Sat, Jan 11, 2025 at 9:43 AM, ok1mlg via groups.io <ok1mlg@...> wrote: Please explain this to me. My approach is that I want all applications to be "unified". This means that if I want a 24h time-format, I want to see it in all my installed applications. Why is your approach that you want to see applications in 12h-format, but QLog in 24h?
To be honest, the change is trivial in QLog. We are talking more about it here than it would mean to change it. For me, it is more important to understand this difference. After all, this problem is not only about the 12/24 format, but about the whole date/time formatting. pá 10. 1. 2025 v?20:11 odesílatel Michael Morgan via <cmorgan13= [email protected]> napsal: I agree that is one the few things that is awkward with the app for me.? I would like for the app to show 24 hour UTC time everywhere - log entries, clock etc. ?but I don't really?want my whole mac showing 24 hour time, guess I'm just to lazy to have to math the times since I use it not only for ham tasks.? I've been trying to work out a script?to launch different things (rigctld so I can share my radio with QLog and other apps, do commands so WSJT laucnhes happy and also my steppir/amp controller apps, etc.) So I could technically put the LC command in there but since last step currently is to launch rigctld since it holds the terminal I wouldn't be able to then launch QLog so it would take the LC command.? I'm sure there maybe a way in applescript to launch it or launch multiple ?terminals or something.? Got to figure that out.
On Fri, Jan 10, 2025 at 10:09?AM Kevin Loughin via <loughkb= [email protected]> wrote: I am a youtube presenter that does mostly ham radio videos.? As such, through comments on my videos, I have a good impression of the general audience technical abilities.
?
That said,? I recently reviewed Qlog,? my new favorite logging software and I love it.? The perfect balance between features and simplicity.
?
In my recent post about the clock and 24 hour time, one response pointed me to the wiki tip about setting an LC system variable to get the program to display 24 hour time.? Thank you, that solved MY problem.? However, I can state with confidence that the majority of the potential user base for this program are not at the skill level or competency required to be digging around in system configuration files and setting system variables.
?
So, I would like to request a simple preference setting,? a toggle between local and UTC time.? In local mode, the clock would behave as it does now, basing it's display on the local system settings.? In UTC mode, the clock would display 24 hour time and align it's offset to UTC.??
This could either be a setting in the preferences panel, or, ideally, a widget within the clock panel itself, allowing the user to toggle the time format as needed depending on their operating environment at the time.
?
This would enhance the intuitiveness of the interface with regard to the clock display, and work for the entire potential user base.
?
Thanks for any consideration,
Kevin - KB9RLW
|
Thanks for another great release!!!
Just some notes:? - had to redownload all the source.? git pull command didnt worked.
- for some reason had to download hamlib 4.5.? QLog didnt liked the latest hamlib.? Tried compiling several times, even downloading manually instead of git command, but didnt worked.? It worked fine with rigctl version 4.5.5.
- had to download manually the flags folder, when downloaded the flags folder was empty.
Other than that, so far so good...
Thank you Michael.
so 11. 1. 2025 v?15:09 odesílatel Michael Morgan via <cmorgan13= [email protected]> napsal: I’ve uploaded the MacOS build:
|
Let me inform you that a new QLog release v0.41.0 is finished.
Changelog:
- [NEW] - Logbook - Added a new context menu item - Update QSO from Callbook (issue #450 @aa5sh)
- [NEW] - DIGI mode is used in case of DXC Digi Spots (issue #480)
- [NEW] - DXC - Retrieve information about SOTA, POTA, IOTA and WWFF from comment (issue #482)
- [NEW] - Alert - Added SOTA, POTA, IOTA and WWFF filter
- [NEW] - Added the COM Port Completer for Windows platform (issue #490)
- [NEW] - Settings - Added DXCC Confirmed By options (issue #508)
- [NEW] - Added POTA Export Formatter (activator/hunter) (PR #514 @kyleboyle)
- [NEW] - CW Console - CW Halt with the user-defined shortcut (issue #518)
- [NEW] - Added an input parameter to save debug message to file
- [NEW] - Logbook - Added sorting function to logbook table columns (PR #540 @kyleboyle)
- [NEW] - Network Notification - Added Rig Status Notification
- [NEW] - Implemented ADIF 3.1.5
- [NEW] - ADIF 3.1.5 - Added new submodes FSKH245 and FSKH105 for HELL
- [NEW] - ADIF 3.1.5 - Added new contest IDs
- [NEW] - ADIF 3.1.5 - Added new columns (Import/Export only)
- [NEW] - ADIF 3.1.5 - Added My DARC DOK to Station Profile
- [CHANGED] - Settings: disabled band and mode name modification
- [CHANGED] - DX Stats contain all enabled bands (issue #538)
- [CHANGED] - Removed Freq, TimeDate On/Off Data Type Indicators (issue #552)
- [CHANGED] - ADIF 3.1.5 - VUCC and MY_VUCC can contain 6 or 4-chars locators
- [CHANGED] - Stop exporting default value N for qsl_rcvd, qsl_sent, lotw/dcl/eslq_qsl_rcvd/sent
- [CHANGED] - Extended QSL/Import Dupe matching rule to Callsign, Band, Mode, Time and Sat_Name (issue #563)
- Fixed MacOS - keep floating windows visible on app unfocus (issue #530)
- Fixed Contest Filter ignores the first QSO (issue #529)
- Fixed It is not possible to quit Qlog with detached widgets Rot & Rig (issue #534)
- Fixed ADX/CSV/JSON do not export non-ASCII chars (issue #542)
- Fixed Checking the 60m checkbox in cluster filters allows 160m spots to appear (issue #543 @aa5sh)
- Fixed Problems uploading to QRZ.com (issue #559 PR #561 @aa5sh)
- Fixed DX Stat screen is jumping up/down
- Fixed Omnirig drivers: Digi modes are not correctly recognized
HAMLIB Upgrade
- Windows and Flatpak packages now include Hamlib v4.6.
Changelog:
Wiki Changelog:
Mike - K3SNO, #707
WW4DX
Slav, EI6KW
Joel Vazquez, WE0DX
Roy Jackson