QLog feedback and improvement suggestion #704
Replies: 7 comments 3 replies
-
|
Thank you for the feedback. Let me respond to some of your improvements.
This is implemented in Bandmap and Alert. It is intentional, because DXC is considered more as a source of information. The reason why Spots are not deleted is that it allows searching far back in time. It's also a performance consideration—when connected to the RBN, there can be a large number of Spots, and deleting them would be too time-consuming. I had quite a bit of "fun" tuning issues of this kind in Bandmap.
The goal of QLog is to keep things as simple as possible. That includes the settings as well. Colors are assigned statically because most users leave things at their default settings anyway, so there's no need to provide customization. It's also because I have full control over the design and I know exactly which colors are being used.
Use DXC Filter Setting and set disable Log Status = "Worked"
It's intentional. The goal is to reduce various settings that are not primarily needed in the GUI.
here you are not sure what exactly you mean. Bandplan contains the time of the spot, DXC contains the time of the spot. Alert Widget contains the last update time.
use Alert Widget to define a rule, which will inform you that the call is reported. You can use a regexp or exact callsign
use Alert Widget for it. You can use a regexp or exact callsign |
Beta Was this translation helpful? Give feedback.
-
|
Ladislav,
Many thanks for your feedback.
I do see some colors in the dx cluster window, and they are sufficient, so let's not argue about something which is there and works. As long as the spots are distinguished a person just need to get used to the default colors. So I agree with you
Filtering DX spots, pota, wwa etc .. Works... just tested it and again, we can close this topic. Bit different way how everyone else does it, but I can get used to it. Again, thumbs up!
I like your approach about the UX/UI, not going to question it, you did a great job so far, so I'll just learn the quirks, again, thinking, your software is top notch!
I also understand that deleting spots can be time consuming. Your log I have to say is maybe the fastest log on windows, and I'm just not bragging here for you, i'm just stating what I have found comparing it to the majority of others. Great job!
However, I do think you should reconsider how the spots are shown - meaning, if I worked it, I don't want to see it, unless there is a button - checkbox - "show worked before". I work the station, the spot is there, half an hour later I look again, the stop is there, clicking on it, thinking I need it while I don't need it.
I think this can be solved in one of the possible ways, so we have plenty of option:
1.
Allow operator to right click on the spot - REMOVE ...
2.
Automatically remove the worked spot after logged contact appears in the log (maybe an addition -> create new column - worked, in the column say - date/mode), that way the op know if the spot was worked and even if it stays there, then can clearly distinguish if the station is needed or not
3.
Automatically change the colour of worked spot to something which can distinguish if the spot was worked or not - again, visually de-cluttering the dx cluster window
The same would apply for Alerts - again, I see it works well now, but if I work the spot, why should I see it there? 2 options:
1.
Automatically remove the spot
2.
Let operator remote the spot - right click - remove
You and your team did a fantastic job. I'm just trying to give you a fresh pair of eyes here, nothing else. Not criticizing it, just offering improvements, nothing else. People don't have to use them.
I now have a alerts window full of spots, half of them I worked and they are still there:
[cid:b25bd6d9-7cf6-438e-9ee3-1f2ccb81f066]
Plus "Updated field" does nothing, stays on 0 ...
I love your log and I would appreciate if you can think about my little improvements.
Oliver
OM0RX
…________________________________
From: Ladislav ***@***.***>
Sent: Friday, July 18, 2025 12:29 PM
To: foldynl/QLog ***@***.***>
Cc: OM0RX ***@***.***>; Author ***@***.***>
Subject: Re: [foldynl/QLog] QLog feedback and improvement suggestion (Discussion #704)
Thank you for the feedback. Let me respond to some of your improvements.
Spot Expiration: Introduce a configurable timeout (e.g., 1–3 hours) to clear old spots. Currently, they persist all day, cluttering the view.
This is implemented in Bandmap and Alert. It is intentional, because DXC is considered more as a source of information. The reason why Spots are not deleted is that it allows searching far back in time. It's also a performance consideration—when connected to the RBN, there can be a large number of Spots, and deleting them would be too time-consuming. I had quite a bit of "fun" tuning issues of this kind in Bandmap.
Customizable Spot Coloring: Allow users to define colors for different states (e.g., worked, needed for an award, band/mode-specific).
The goal of QLog is to keep things as simple as possible. That includes the settings as well. Colors are assigned statically because most users leave things at their default settings anyway, so there's no need to provide customization. It's also because I have full control over the design and I know exactly which colors are being used.
Auto-Removal of Worked Stations: Spots should disappear from the cluster list once logged to avoid clutter.
Use DXC Filter Setting and set disable Log Status = "Worked"
Quick Band/Mode Selection: Add a toolbar or dropdown for faster filtering without right-clicking.
It's intentional. The goal is to reduce various settings that are not primarily needed in the GUI.
able to see the "age" of the spot. Again, with one look I know how old is this spot, let's say 45 minutes and I know my chances are low, it might not be there anymore or it's worth to still have a look
here you are not sure what exactly you mean. Bandplan contains the time of the spot, DXC contains the time of the spot. Alert Widget contains the last update time.
Filter by DX call (e.g., show only "C93" spots).
use Alert Widget to define a rule, which will inform you that the call is reported. You can use a regexp or exact callsign
Filter by comment (e.g., display only spots containing "POTA" or "WWA").
use Alert Widget for it. You can use a regexp or exact callsign
—
Reply to this email directly, view it on GitHub<#704 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKPZ6H6HEJN3PPJKJWMDSEL3JDECJAVCNFSM6AAAAACB2B3XI2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOBQGQ3DQMY>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
One more thing which I just spotted:
[cid:4d13a744-ec44-4043-b0cf-fd5dff57138b]
You can see in the Alerts window RI0CR on CW / 20m. But I have already worked him on CW /20m.
This is confusing. My opinion is that you should not see the alert if you have worked the station on particular mode / band. If you do, it kind of make it useless. I have an alert which I have setup but I don't need it.
I do strongly think this correct behavior would benefit many, this is not just only about myself. I'm just trying to make suggestions which more operators would appreciate.
I'm sorry, I do see strong product here, with a few tweaks there will be nothing better as fat ham radio logging software than qlog ...
Oliver
OM0RX
…________________________________
From: ***@***.*** ***@***.***>
Sent: Friday, July 18, 2025 2:54 PM
To: foldynl/QLog ***@***.***>; foldynl/QLog ***@***.***>
Cc: Author ***@***.***>
Subject: Re: [foldynl/QLog] QLog feedback and improvement suggestion (Discussion #704)
Ladislav,
Many thanks for your feedback.
I do see some colors in the dx cluster window, and they are sufficient, so let's not argue about something which is there and works. As long as the spots are distinguished a person just need to get used to the default colors. So I agree with you
Filtering DX spots, pota, wwa etc .. Works... just tested it and again, we can close this topic. Bit different way how everyone else does it, but I can get used to it. Again, thumbs up!
I like your approach about the UX/UI, not going to question it, you did a great job so far, so I'll just learn the quirks, again, thinking, your software is top notch!
I also understand that deleting spots can be time consuming. Your log I have to say is maybe the fastest log on windows, and I'm just not bragging here for you, i'm just stating what I have found comparing it to the majority of others. Great job!
However, I do think you should reconsider how the spots are shown - meaning, if I worked it, I don't want to see it, unless there is a button - checkbox - "show worked before". I work the station, the spot is there, half an hour later I look again, the stop is there, clicking on it, thinking I need it while I don't need it.
I think this can be solved in one of the possible ways, so we have plenty of option:
1.
Allow operator to right click on the spot - REMOVE ...
2.
Automatically remove the worked spot after logged contact appears in the log (maybe an addition -> create new column - worked, in the column say - date/mode), that way the op know if the spot was worked and even if it stays there, then can clearly distinguish if the station is needed or not
3.
Automatically change the colour of worked spot to something which can distinguish if the spot was worked or not - again, visually de-cluttering the dx cluster window
The same would apply for Alerts - again, I see it works well now, but if I work the spot, why should I see it there? 2 options:
1.
Automatically remove the spot
2.
Let operator remote the spot - right click - remove
You and your team did a fantastic job. I'm just trying to give you a fresh pair of eyes here, nothing else. Not criticizing it, just offering improvements, nothing else. People don't have to use them.
I now have a alerts window full of spots, half of them I worked and they are still there:
[cid:b25bd6d9-7cf6-438e-9ee3-1f2ccb81f066]
Plus "Updated field" does nothing, stays on 0 ...
I love your log and I would appreciate if you can think about my little improvements.
Oliver
OM0RX
________________________________
From: Ladislav ***@***.***>
Sent: Friday, July 18, 2025 12:29 PM
To: foldynl/QLog ***@***.***>
Cc: OM0RX ***@***.***>; Author ***@***.***>
Subject: Re: [foldynl/QLog] QLog feedback and improvement suggestion (Discussion #704)
Thank you for the feedback. Let me respond to some of your improvements.
Spot Expiration: Introduce a configurable timeout (e.g., 1–3 hours) to clear old spots. Currently, they persist all day, cluttering the view.
This is implemented in Bandmap and Alert. It is intentional, because DXC is considered more as a source of information. The reason why Spots are not deleted is that it allows searching far back in time. It's also a performance consideration—when connected to the RBN, there can be a large number of Spots, and deleting them would be too time-consuming. I had quite a bit of "fun" tuning issues of this kind in Bandmap.
Customizable Spot Coloring: Allow users to define colors for different states (e.g., worked, needed for an award, band/mode-specific).
The goal of QLog is to keep things as simple as possible. That includes the settings as well. Colors are assigned statically because most users leave things at their default settings anyway, so there's no need to provide customization. It's also because I have full control over the design and I know exactly which colors are being used.
Auto-Removal of Worked Stations: Spots should disappear from the cluster list once logged to avoid clutter.
Use DXC Filter Setting and set disable Log Status = "Worked"
Quick Band/Mode Selection: Add a toolbar or dropdown for faster filtering without right-clicking.
It's intentional. The goal is to reduce various settings that are not primarily needed in the GUI.
able to see the "age" of the spot. Again, with one look I know how old is this spot, let's say 45 minutes and I know my chances are low, it might not be there anymore or it's worth to still have a look
here you are not sure what exactly you mean. Bandplan contains the time of the spot, DXC contains the time of the spot. Alert Widget contains the last update time.
Filter by DX call (e.g., show only "C93" spots).
use Alert Widget to define a rule, which will inform you that the call is reported. You can use a regexp or exact callsign
Filter by comment (e.g., display only spots containing "POTA" or "WWA").
use Alert Widget for it. You can use a regexp or exact callsign
—
Reply to this email directly, view it on GitHub<#704 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKPZ6H6HEJN3PPJKJWMDSEL3JDECJAVCNFSM6AAAAACB2B3XI2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOBQGQ3DQMY>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
The screenshots are not coming through if you paste them in email, you have to paste them on GitHub. I like the idea of when a station is logged having it scan the DXWidget/BandMap and update the status of any records in the Dataset to Worked. The Alerts window and Rules took a minute for me to get my head wrapped around, but once I did I like it, since it is an aggregator for both the DX Cluster spots and WSJTX spots. Michael, AA5SH |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
alerts as an aggregator is a neat idea and I actually love it, never seen it on another log, however, aggregating useless information is not advisable. I might be mistaken, and I have no problems to apologize, but why seeing spots I worked / having them in the cluster or alerts area is a good idea? If someone wants it, have a wrkd b4 button there, easy, then see it, otherwise it is an unnecessary clutter .. I understand we might have different opinions, and that's ok, I will be happy to change mine, but at this moment I can't see it? |
Beta Was this translation helpful? Give feedback.
-
|
You can adjust the alerts rules to not show worked. Also the alerts window does update when you work a station so it will fall off if there. For instance on mine I like seeing details in the DX Cluster list but on the Alerts just give me New Slots ,Countries or whatever. I have several rules setup: But I don't see worked stations in the Alerts window. Just unconfirmed. |
Beta Was this translation helpful? Give feedback.
-
|
Lovely, I got similar setup. However, maybe I have not explained myself properly. Please, accept my apology. It's not about seeing the alerts, its about seeing it after you have worked it. What is point to have it sill on the list after the qso is logged in the log? That's my problem. Same for the DX window, if I have worked the spot, it should not be there. ... Hopefully this explains better what I am talking about. And I don't want to even start with superb extra functionality which would take this to another level:
I have not seen this anywhere. I know this is not easy to implement. But just think about it, how great would this be? I like simple things, I love Qlog, it's simple, but the same time powerful. It's just the dx spot clutter which puts me off a little.. |
Beta Was this translation helpful? Give feedback.
-
|
Ovelir, now I understand what you mean. Yes, in this case, the filter with "Worked" cannot help. The functionality you're describing is implemented in contests as a DUPE check. In contests, there is a limited and simple rule set when a QSO is considered a DUPE. And that's the issue in your case. You’re describing possible situations where a QSO should be excluded from DXC. Should it be excluded only for a specific band? If I worked the station today, do I want to see it again tomorrow or a year from now? In a contest, I probably want to see callsigns I’ve already worked, or not ? Should POTA, SOTA, or other Special Interest Groups be taken into account? I could list many more criteria that could be used to remove QSOs from DXC. I believe it’s not a problem to define such criteria — there will be many and many rules, but it will definitely be a finite set. The real question is how to present this to the user. Every user has a different idea and special interest of which QSO they want to see or not see in the DXC. Unfortunately, this is a constant issue during QLog development — everyone has their own individual requirements. These must be considered, but not at the expense of GUI clarity. Even if I consider not deleting QSOs but simply changing their color, the question still remains: how do we define the rules that determine which QSOs get marked? Please try to come up with an idea on how to present this to users, what all criteria should be included and how to minimize the need for setting criteria. You might see it from a different perspective than I do. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your thoughtful response. I completely understand the challenge of balancing user-specific needs with GUI clarity. Your point about contest-style dupe checks versus general logging is valid—the rules are more complex outside contests. However, I believe we can find a middle ground that addresses the core issue without overwhelming users with options.
Suggested Solution: A "Hide Worked" Toggle with Customizable Rules
Instead of implementing rigid filters upfront, why not start with a simple but expandable system?
1.
Basic Toggle (MVP):
*
Add a checkbox "Hide Worked" in the DX Cluster panel.
*
When enabled, spots for callsigns already in your log (matching call + band + mode) are hidden.
*
This covers 80% of use cases (e.g., avoiding accidental repeats on the same band/mode).
2.
3.
Optional Advanced Rules (Configurable):
*
For users who need finer control (e.g., POTA/SOTA, time-based rules), add a gear icon next to the toggle to open a settings dialog.
*
Example options:
*
"Hide only if worked today" (vs. "ever")
*
"Exclude POTA/SOTA activations from hiding"
*
"Ignore mode/band differences" (hide all worked callsigns regardless of band)
*
4.
Visual Feedback for Hidden Spots:
*
If hiding spots entirely feels too abrupt, consider:
*
Graying out worked spots (strikethrough optional).
*
A small icon (e.g., ✅) to indicate "worked" status.
Regardless of the advanced rule-based solutions discussed earlier, perhaps the most straightforward compromise would be:
1.
Auto-Remove Worked Spots (Core Fix)
*
Spots for stations already worked (call + band + mode) are automatically hidden from the cluster.
*
Rationale: This prevents accidental re-selection of logged QSOs, reducing clutter and operator frustration.
2.
"Show Worked Before" Toggle (Flexibility)
*
A checkbox ("Show Worked") allows operators to display hidden spots if desired (e.g., for multihop/multimode opportunities).
*
Worked spots appear in a distinct color (e.g., light fblue) to differentiate them from new ones.
3.
POTA/SOTA/IOTA Exception (Optional)
*
A second checkbox ("Include POTA/SOTA/IOTA") could override the hiding rule for activations, leveraging QLog’s excellent regex-based matching.
*
Rationale: Many operators still want to see activations even if worked (e.g., for different bands/hunters).
4.
Why This Works
5.
Clean Default: The cluster shows only unworked spots by default—ideal for most casual or contest-style operating.
6.
User Control: Toggles let operators bypass filters when needed (e.g., DXpedition hunters checking for new band/mode slots).
7.
Visual Clarity: Color-coding avoids confusion while preserving all data.
8.
Low Complexity: No elaborate rules—just two checkboxes and auto-hiding based on logbook checks.
This mirrors how tools like DXLab’s Spot Collector or RumLogNG handle worked spots: "Hide unless I ask to see them." It’s a proven middle ground between automation and flexibility.
Would this address your concerns about UI clutter while keeping customization manageable?
…________________________________
From: Ladislav ***@***.***>
Sent: Saturday, July 19, 2025 10:36
To: foldynl/QLog ***@***.***>
Cc: OM0RX ***@***.***>; Author ***@***.***>
Subject: Re: [foldynl/QLog] QLog feedback and improvement suggestion (Discussion #704)
Ovelir, now I understand what you mean. Yes, in this case, the filter with "Worked" cannot help. The functionality you're describing is implemented in contests as a DUPE check. In contests, there is a limited and simple rule set when a QSO is considered a DUPE. And that's the issue in your case. You’re describing possible situations where a QSO should be excluded from DXC. Should it be excluded only for a specific band? If I worked the station today, do I want to see it again tomorrow or a year from now? In a contest, I probably want to see callsigns I’ve already worked, or not ? Should POTA, SOTA, or other Special Interest Groups be taken into account? I could list many more criteria that could be used to remove QSOs from DXC.
I believe it’s not a problem to define such criteria — there will be many and many rules, but it will definitely be a finite set. The real question is how to present this to the user. Every user has a different idea and special interest of which QSO they want to see or not see in the DXC. Unfortunately, this is a constant issue during QLog development — everyone has their own individual requirements. These must be considered, but not at the expense of GUI clarity.
Even if I consider not deleting QSOs but simply changing their color, the question still remains: how do we define the rules that determine which QSOs get marked?
Please try to come up with an idea on how to present this to users, what all criteria should be included and how to minimize the need for setting criteria. You might see it from a different perspective than I do.
—
Reply to this email directly, view it on GitHub<#704 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKPZ6H2PJKUTT4PAC4RAYVD3JH7RRAVCNFSM6AAAAACB2B3XI2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOBRGU2TANI>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
As a new QLog user with 30 years of experience in IT—including software project management and developer oversight—I believe I can offer a well-informed perspective on logging software.
Recently, I switched from macOS to Windows due to stability and performance issues with ExpertSDR3 on macOS. This change required me to find a new logging solution. My longtime favorite, RumLogNG (macOS-only), is, in my opinion, the gold standard for ham radio logging. After testing various Windows alternatives—many of which feel outdated in terms of UI/UX, performance, and features—I was pleasantly surprised to discover QLog.
Why QLog Stands Out:
Comprehensive online services support, including WaveLog
Where QLog Excels:
I’m highly selective when it comes to software, but I must commend the QLog development team for creating such an impressive product. It’s rare for me to be genuinely impressed, but QLog has achieved that.
One Area for Improvement: DX Cluster Implementation
While functional, the cluster interface could be more refined. Here are my suggestions:
Advanced Filtering:
These enhancements would make QLog’s cluster functionality as powerful as its other features—solidifying its position as the best logging software across Windows, macOS, and Linux. Given the importance of cluster operation in modern ham radio, optimizing this aspect would be a game-changer.
Thank you for your excellent work. I’m excited to see how QLog evolves!
Best regards,
Oliver (OM0RX)
Beta Was this translation helpful? Give feedback.
All reactions