feature request: Add "--gui" option

[WheezyE]

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]

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]

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.