search

pflarue / ardop

ardopcf - A multi-platform implementation of the Amateur Radio Digital Open Protocol (ARDOP)
Other
30 stars 7 forks source link

feature request: Add "--gui" option #49

Closed WheezyE closed 4 months ago

WheezyE commented 6 months ago

I love the --webgui PORTNUMBER commandline option for its compatibility with users who wish to run ardopcf from a headless SBC and connect over the SBC's wifi.

I think having a --gui commandline option could help ardopcf to one day replace the ARDOP_Win.exe that's currently bundled in Winlink Express. Winlink Express could run then ardopcf with the --gui flag so that users would not notice any disruption in how they expect ARDOP to behave when invoked from Winlink Express.

Another idea would be to have the GUI come up by default (to aid newbie users), then have a --headless flag that could be passed to ardopcf to save CPU cycles for users who want to run ardopcf on battery power in the field.

Dinsmoor commented 5 months ago

I think that ARDOP_GUI is a completely separate project, but it should probably be forked and worked on too. Do you know anyone interested in maintaining a cross platform GUI with the waterfall and decoding constellation?

This project is just the ardopcf modem - but as far as I know, the ARDOP_GUI on John Wiseman's website should work with this. The UDP interface hasn't been touched.

pflarue commented 5 months ago

The --webgui option mostly is useful to define a port number for the connection. The difference in resource use between using this option but never connecting to it versus not specifying a port number should be minimal. I never thought to verify this, but it would be easy enough to confirm. If my assumption was incorrect, it shouldn't be too hard to make it true. So, adding a --headless option wouldn't likely have any benefit. However, setting a default port number for the Webgui might be a reasonable idea, such that the --webgui option is only required to allow a different port number to be chosen.

I'm not sure whether your meaning of "have the GUI come up by default" was simply to have it enabled by default (as defining a default port number would provide), or if you mean you want a browser window to be automatically opened. I do not think that the latter is practical in a simple cross-platform way.

While John Wiseman's ARDOP_GUI was a useful tool, I hope that support for it and the UDP interface it connects to can be phased out from ardopcf once any bugs in the Webgui are worked out. The UDP transport is not compatible with a browser based GUI, which I felt was useful as the easiest way to create a truly platform independent interface that would work anywhere s GUI could be possible. The reverse is not true. If someone wanted to build a standalone GUI program for ardopcf, it could communicate with ardopcf using the interface used by the Webgui (though I'd ask that this wait a while in case issues are found with the Webgui requiring breaking changes to its communication protocol). However, I can't currently think of any advantage to doing so. One of the great things about this bring an open source project is that if somebody else does see an advantage of building a standalone GUI, or if integrating a GUI into a host for ARQ or FEC communication, they are free to do so.

I also don't know whether getting Winlink Express to use ardopcf in place of Ardop_win is worth pursuing. I consider work on ardopcf important because ardopc needed/needs fixing. Ensuring that ardopcf also works on Windows is intended to also provide support for Pat winlink or other host programs on Windows, not necessarily Winlink Expresss. I don't currently know of any problems with Ardop_win that require further development. If problems are found with it, then exploring the possibility of resuming support for it would be a viable alternative to getting Winlink Express to use ardopcf.

WheezyE commented 4 months ago

Thank you both for your insights on this one. I think you're right that ARDOP_Win.exe in Winlink Express is doing ok on its own as its own thing for now and maybe doesn't need to be replaced for now. I also didn't realize ARDOP_GUI was compatible with ARDOPcf and also am reconsidering the need for a built-in GUI (other than the --webgui).

This feature request was based on my own personal interested in having a drop-in replacement for ARDOP_Win.exe in Winlink Express to run on wine-mono since I thought it was broken, but I've been able to debug the wine-mono issue I was having in https://github.com/WheezyE/Winelink/issues/88 and no-longer am as interested in a drop-in replacement.

I really appreciate you both. I'll close this issue for now. Thank you!