JS8Call-improved
Replies: 48 comments 73 replies
|
I would like to see something done to change how the MSG inbox works. Possibly look at ways to integrate it into the main window. I think this was discussed briefly in a issues thread but I haven't had time to look at it. |
|
Absolutely! Just don't ask me for specifics though :) |
|
@Chris-AC9KH I've been giving this some thought. I'd like to see it be dockable, so it can be its own window as it is now, but dock into the main window if desired. That would have major implications for the way everything else works. |
|
Hi there, JS8 can send out APRS TEXT MESSAGES. I would like to see an ACK and also the ability to receive a REPLY to an APRS MESSAGE I send! I think this will create a lot of interest on JS8. |
|
Also a way to compose an APRS TEXT MESSAGE and possibly APRS E-MAIL in JS8 MENUS would be a nice improvement too! This way we will not need to remember the correct syntax and also there will be no need to run an external program to create these. |
|
Have you looked at the JS8spotter add-on? It simplifies APRS messaging. |
|
A built-in mapping interface and true off-grid time synchronization, using WWV and CHU time signals to automatically set and maintain accurate system time without internet cellular access, or GPS |
It's your lucky day. This is already in beta testing! |
|
WOW, thank you! |
|
Seamless integration with meshtastic |
|
I'm thinking this would be best left to the api. |
|
I agree, it's definitely doable through the API. I have a project @ http://AI5TS.com does this and the biggest issue is allowing non licensed operators to forward through HF, seems to be a legal minefield. Currently, I use my program as a means to operate JS8 from my phone like a texting app |
|
Make JS8Call fully touch-friendly so all menus, buttons, and common actions work without a keyboard. Include an optional on-screen alpha/numeric pad for message input. This will improve usability on touch-enabled devices tablets ect during field or EMCOMM operations. |
|
So, is this a request for desktop OSes, or android/ios? We have an official android port that @punk-kaos is working on, and there was discussion about an iOS port. |
|
I actually meant desktop OSes Linux and Windows. There are plenty of Windows and Linux tablets, 2-in-1s, and similar devices where having touch support would be really useful. |
|
@Chris-AC9KH I've got the message window docking, it works well except on Wayland (of course), so I'm having to come up with some work-arounds, but it's happening. |
|
@rruchte this will be cool! The main issue with docking was that the unread flag does not clear in the callsign list until the window is closed. And, of course, that it does not remember the window position, or re-open it, if the program is stopped and restarted. Wayland is a bit different from other window managers because it doesn't implement remembering window size and position like others do, but it doesn't specifically prevent applications from implementing it. This will be fun to try out when you get some code ready for testing. |
|
Should be a way to change the read status when you click on the message. Waiting to clear on window close is strange. |
|
@wmiler Agreed, that's the plan. The problem with Wayland is that when the panel undocks, the frame will not accept mouse input, so it cannot be moved or re-docked, only closed. If there is no way to solve that, we will have to do something like embed the widget in a QDialog (sort of like it is now) when undocked, then move it back to the dock on a button click or something. That's less than ideal, I would prefer to just do it all the "QT Way", because otherwise the UI is going to be clunky. So we can either have it just be broken on Wayland, handle things differently for Wayland only, or use the same workaround on all platforms. I don't really like any of those options. |
|
@rruchte maybe this is repeatable on other platforms too? When you have a branch where it can be tested, let me know and I'll try it out. I can run all all three supported systems on one computer simultaneous for testing it. |
|
Sure, you can check it out here: https://github.com/rruchte/JS8Call-improved/tree/enhancement_dockable-msg-window I was mistaken about the inability to re-dock the floating panel, that does work for me but the hitbox for the icon is tiny. So the only problem is that the popup cannot be moved. Looks like a known thing, I'm not sure where this leaves us: https://qt-project.atlassian.net/browse/QTBUG-87332#icft=QTBUG-87332 |
|
Mechanically, docking, undocking, moving it around etc. works fine on MacOS. It is not persistent, i.e. it doesn't remember to open the message window on a program restart. But that would require saving such a setting in the JS8Call.ini. However, it does remember the pane layout properly when the message window is re-opened later. Can't you just double-click the title bar for a re-dock Rob? That's the way docked/undocked windows normally work. |
|
Yeah, none of those details are ironed out yet, I'm just concerned about the higher level mechanics at this point. There is probably a way to double click to dock, if that's what we want to do. If it's fine on other platforms, maybe it's acceptable to just blame the inability to move the undocked panel in Wayland on QT and wait for an upstream fix. Sucks for me because I'm on Wayland, but I run on a widescreen display and can just keep it docked. Not sure others will be willing to accept the defect though. I'll just move forward with the details like remembering state and handling viewed message changes appropriately. |
|
Rob, double clicking to re-dock works perfectly on MacOS. Haven't tested it on the other two platforms yet until I get good "feel" for how it works on Mac. Then I'll build it on Windows 11 and Debian 13 trixie and try it out. I think the double-click re-dock is something that's built into the basic desktop system and is not necessarily a "feature" you can add with Qt. But otherwise, mechanically it works perfectly on Mac. I can undock it, move it where ever I want, resize the window, etc.. Double click the title bar and it goes back exactly to how I had it sized and laid out in the main window when it re-docks. I'm waiting right now to get an incoming MSG to see if will clear the message notification flag when I select the MSG in the list, but maybe that hasn't been dealt with yet. |
|
I have not altered the message flag clearing logic yet, I have only focused on the higher level mechanics of getting the dock working. |
|
@rruchte the message window docking works on Debian 13 KDE with Wayland compositor the same as on MacOS. Double click on the title bar docks or un-docks. Can drag the window around and resize it, whatever. Double click the title bar and it goes back to being docked with the same configuration it was in before. I don't actually see anything wrong with it. |
|
Huh. Maybe it's a Gnome/Wayland thing. Well that's good news. |
|
Hmm, I'll have to look at it at some point then, since I'm running gnome/wayland here. I'm not sure how far Wayland has gotten on all their positioning stuffs, just "it's in progress". I doubt we will see improvements before the next gnome/ubuntu release cycle...sigh. |
|
So as a follow up, it seems to work correctly for me on Ubuntu 24.04. Have not tested it as an AppImage yet. |
|
Thanks Wyatt, must just be my janky installation. The Arch rolling release model works great until it doesn't. At 5.5 years, I think I'm pushing my luck. |
|
It also works on Windows 11 identical to MacOS. If get an incoming MSG it doesn't refresh and show that until you close the window and reopen it. And it won't clear the MSG notification flag until you close it. But the mechanics of the docking/un-docking work perfectly. |
|
JS8Call 2.6.0 is tentatively scheduled for a release date of May 1, 2026. |
|
Before people get too excited about 2.6.0, this is not likely to happen. At this point the next version of JS8Call will be 3.0, mainly because we're making an API change, going from the Hamlib 4.6-series to 4.7, and it is the first major release after a complete refactor of the codebase. I changed the compile order of the object code and how it is linked. That's a pretty significant overhaul under the hood since we're now building member functions of the UI_Constructor class as separate objects and the UI_Constructor class didn't even exist in 2.5.0. The patch releases for 2.5 are built on the old codebase. So going to 2.6, which is just a minor version increment does not make sense. JS8Call should've gone from 2.2. to 3.0 when the port to C++ was done. But semantic versioning wasn't being followed back then so it is what it is. We have done a similar thing again, which COMPLETELY changes how the code is built and linked, which is a major version increment under the rules of semantic versioning. Not even the build system is backwards compatible with 2.5 after I overhauled the codebase. Try dropping the current CMake configuration into 2.5 and let me know what happens. |
|
Admittedly when this poll came out, 2.6 was the expected next iteration, and not all the listed items had landed. Perhaps on the next one of these poll type questions, it should be called "JS8Call-next". I'm ok with moving to 3.0, we have done a ton of work that fully qualifies the bump. |
|
It's a little unfortunate at this point that it was not moved to 3.0 after the port to C++. But that's water under the bridge now. |
|
Yeah, there's certainly enough changes to warrant it. |
|
The writing is on the wall that it's the end of the line for Intel-based Macs. More software vendors are going to just Apple silicon builds now. 
Support doesn't officially end until Tuesday September 15. So I'm thinking at this point that the next JS8Call release will have an Intel build but that's probably the final one. The last Intel-based Mac was the 2019 Mac Pro and that's 7 years ago now. The few people left running Intel processor Macs will still have the option to roll their own using the build instructions. But even that is getting is more difficult since the Qt Group does not support building Qt on Intel Macs after 6.8.3. In reality, the x86_64 architecture itself is a dodo bird. It never was a true 64-bit system. It's a 32-bit system with extensions, but it still only uses 48-bit addressing so its instruction sets default to 32-bit operands. They clock the living hell out of it to get thruput, but that only uses more power which is not suitable for today's mobile devices. With Intel on the verge of bankruptcy, and is now a U.S. government-funded company, x86_64 has one foot in the grave and the other on a banana peel. |
|
I'm ok with killing off Intel Mac with the 3.0 release cycle. |
|
I can still provide a Intel build sometime early to mid-summer. If after that, and users want, the tools and libraries are provided by us to build JS8Call on an Intel-based machine. But it requires an older version of Xcode and the Mac SDK to build it, which I'm finding increasingly difficult to maintain. |
|
A blocking filter or blacklist would be great. I'm sick of WM8Q spamming JS8 about his "subspace" version of JS8!BrianWN7FOn May 7, 2026, at 19:40, Julian White ***@***.***> wrote:
The ability to filter out specific callsigns that are spamming groups such as @allcall.
I could just leave @allcall I suppose, but that just doesn't seem like the right solution.
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
What sort of block are you guys looking for? So far we have HB blocking, Spotting block and autoreply block. Are you proposing that if a decode from contains a specific callsign, don't display it in band or call activity, or in the incoming MSG pane? That would add a little overhead on the UI to filter each decode. I'd have to explore how much overhead it would add. |
|
I really just don't want to have to scroll through a wall of spam in the yellow msg box. |
|
Ok, so this wasn't too difficult. I added a callsign blocking feature 
All it does is keep the spam from this callsign from appearing in your MSG pane. They will still appear in the band activity, and the call activity. If they send you either a MSG or a directed it won't print in the MSG pane if they're blocked, but the MSG will still go to your inbox if it is a valid MSG. It blocks ALLCALL's and CALLGROUPS as well if the blocked callsign sends to one of those. @kf4mot @Brian-WN7D is this what you were looking for? I can PR this to master and include it in the next release as well. Edit: |
|
Here's the PR if people want to review it #289 |
|
Sounds perfect Chris! And completed in no time. |
|
This request was not too difficult and doesn't add any real overhead. I just basically copied what the spot_blacklist is doing and created a small conditional logic block in mainwindow to implement it. Blocking at the decoder level would've been more extensive. But as long as people don't care if the spammer still shows up in band activity or call activity, that makes it pretty simple to keep them out of your MSG pane. |
|
I hate to come back asking for more, but there's still a desire for keyword filtering. Sounds like a reasonable use case for excluding "sitreps" and such. |
|
All.txt can get quite large over time. Especially for those of us that run 24/7. |
|
Do you also want an auto delete after x months as well? Something along the lines of the linux logrotate? |
|
Personally I'd rather manually delete if I want, but make it a option? |
|
How about just turning it off in the Preferences? It's a logging feature that has no practical purpose for anything but diagnostics. |
|
May be a good option for some. |
Uh oh!
There was an error while loading. Please reload this page.
This thread is to get feedback on what features or enhancements matter to the users that you would like us to work.
Currently, the only large thing being worked on is API updates (#87), and some logging fixes/updates.
Please had your requests below.
All reactions