Open s0lesurviv0r opened 1 year ago
I'd be generally in support. This is the way Winlink Express works and would be easier for many people's use cases.
I'll note, when working on systems with systemd
(Ubuntu, Raspberry Pi) I personally set up systemd
user services to launch the modems in the background independently from Pat, but that doesn't cover every use case.
Awesome. Good to hear. My reasoning for having PAT launch the applications is that I need them on-demand. I have two laptops and they're not always plugged into a rig. When I want to operate I want to be able to plug in my rig and then just use PAT from there. I feel this feature will help the more tactical use cases.
I'll start putting together a PR. Thanks again!
I'm not sure I fully understood the use-case for this. Pat is built to handle modems/rigctl starting up and shutting down. There is no need to restart Pat after you start/stop a modem.
Also, the modems you normally use can be configured to auto-start on boot or when a usb device (e.g. radio) is plugged in to the computer (using udev on Linux).
The only thing I can see is that this would save a "click" (start/stop the modem) if a user for some reason only want the modem to run when in operation, but still want Pat to run continuously on the same machine.
Are there any other use-cases?
I suspect it might be complicated to implement this feature cross-platform, and in a generic way. Some modems have dependencies on other services (e.g. the X server). Also, some are forking, some deamonizes and some are ment to run in the foreground. All this complexity is handled very well by the operating system's service manager (systemd, Services, Launcher etc). Having Pat run a script is simple, but managing another app's running state is a very complex problem I think.
What are we really trying to resolve by implementing this? I think we need to discuss the scope of the feature before we invest a lot of time in implementation and code review 😊
I almost mentioned it: yes, using udev
to launch modems when the radio is plugged in is also a viable and clean solution for a portable/flexible station, but only in certain cases. udev
only works on Linux; macOS has diskutil activity
; and in Windows after a casual search I can't even find a way to run arbitrary scripts/programs based on USB connect/disconnect. Also, the device IDs for many ham radio devices is left as "generic serial device" and clashes with things like GPS receivers in udev
, so it takes some fiddling to get those working properly.
I'm not sure I would personally use Pat to launch modems, but I think there's clear evidence for the need based on e.g. https://github.com/km4ack/patmenu2. Not everyone wants to mess around with udev
rules.
That said, I agree with your points about thinking through the scope and difficulty of managing other subprocesses.
Thanks for the feedback. Here are some points that should illustrate how I operate and why I think this feature would be beneficial:
I appreciate the concerns and agree that it's not straight forward. However:
ardopc
. I'm hoping that one day PAT will support direwolf
for direct Packet Winlink (instead of through the AX.25 stack) and direwolf can run as a foreground process.os/exec
, path
, and path/filepath
packages are robust enough to handle these use cases cross-platform.If these points seem acceptable I'm always happy to write up some sort of implementation plan so we can come to an agreement on that first.
Sorry for the delayed response @s0lesurviv0r.
Sounds reasonable to discuss this further, and write up some implementation plan. Maybe we could write the implementation plan as a PR (a markdown file) so that we can comment and discuss. We should probably start by writing down the scope of this feature, how the configuration params should work and an overview of the most common use-cases.
It would also be interesting to discuss how this would work differently than patmenu2, and the advantages of implementing it as part of Pat. How do you see this? 🙂
Thanks!
I think I should now apologize for my late response. My job was extra busy this last week. I'll submit a PR with a Markdown next week so we can all hash out the details. Thanks again!
Hi there, I'm filing this feature request in order to gauge the level of support for this feature. I'm more than willing to contribute a PR if the maintainers feel it's a good fit.
I'd like PAT to:
The goal is to only have to launch PAT and from there choose modem type and hit connect.
I'm also very curious to know if anyone's attempted this before and/or if there are any pitfalls/pointers they can share. Thanks again!