This is, effectively, one and the same. To be frank, a ground-up rewrite, with a headless service, a well-documented network-accessible API, and a UI, perhaps but not necessarily using the existing one, would be a highly worthy project in its own right.
Could be a nice opportunity for rationalisation. Cheers Tom On Wed, 28 Feb 2024 at 19:01, Alex, VE3NEA via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > Splitting the UI and data processing code would mean a major rewrite of > the project. It might be much easier to implement some > API, e.g. REST-based, for the functions that are currently performed via > the UI. Then WSJT-X would run with its main window > minimized or hidden on the remote system, and the controlling app with UI > would run in the shack. > > 73 Alex VE3NEA > > > On 2024-02-28 13:12, Rafael Pinto via wsjt-devel wrote: > > William, > > > > You got the architecture right. The point is not having to render images > and treat UI events, thus having all processing power > > for mathematical computation. X Windows System and Wayland are memory > and CPU hogs and in some cases those resources are at a > > premium... > > > > As I read the code, trying to figure out how WSTJ-X works, I notice how > tightly coupled UI and data processing are. I understand > > it can be easier to show things on the GUI, but decoupling those could > allow for some different UX (text-only, for example) or, > > as I suggested, some "smart" remoting. > > > > To be 100% honest, the distributed processing approach I proposed is > just a thought experiment on how to decouple the many > > modules. Having each "module" on a different machine is usually how I > think when I try to decouple complex stuff. > > > > I'll keep studying the code to try and figure out how it would be > possible... > > > > 73 > > > > Rafael > > > > On Wed, Feb 28, 2024 at 1:01 PM William Smith via wsjt-devel < > wsjt-devel@lists.sourceforge.net > > <mailto:wsjt-devel@lists.sourceforge.net>> wrote: > > > > I get what you were trying to do, and it is not a perfect solution, > but many people use VNC or some other kind of remote > > desktop protocol to remotely control the computer that is running > WSJT. > > > > Yes, it would be much better to unload the GUI and the output video > requirements from the poor Raspberry Pi and let that run > > on some machine that has a lot more available horsepower. However, > as you are determining, that is a lot of work, and the > > remote desktop thing has the advantage of not requiring any coding > at all from the WSJT team. > > > > 73, Willie N1JBJ > > > > > > > On Feb 28, 2024, at 7:11 AM, Rafael Pinto via wsjt-devel < > wsjt-devel@lists.sourceforge.net > > <mailto:wsjt-devel@lists.sourceforge.net>> wrote: > > > > > > > > > Hello folks > > > > > > Sorry if this has already been discussed! > > > > > > I am Rafael, PU1OWL, and I was thinking if it would be possible > to detach the GUI frontend from the > > modulation/audio/realtime backend of WSJT-X so we can make it a > remote module > > > > > > The architecture I envision is having a remote processor (e.g., > some bulky raspberry pi, a PicoITX i9 board...) dealing > > with the mathematical heavy lifting while not having to put CPU into > presenting its GUI. The GUI could be remote, on a PC or > > another raspberry pi, or something even lighter... Or maybe even > some audio sink board, forwarding to a hugely capable math > > processor, to a lightweight GUI... > > > > > > I started studying the source code, but I cannot find somewhere > to split the code. Has it been tried before? > > > > > > 73 de PU1OWL > > > > > > Rafael Pinto > > > _______________________________________________ > > > wsjt-devel mailing list > > > wsjt-devel@lists.sourceforge.net <mailto: > wsjt-devel@lists.sourceforge.net> > > > https://lists.sourceforge.net/lists/listinfo/wsjt-devel < > https://lists.sourceforge.net/lists/listinfo/wsjt-devel> > > > > > > _______________________________________________ > > wsjt-devel mailing list > > wsjt-devel@lists.sourceforge.net <mailto: > wsjt-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/wsjt-devel < > https://lists.sourceforge.net/lists/listinfo/wsjt-devel> > > > > > > > > _______________________________________________ > > wsjt-devel mailing list > > wsjt-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
