#20: Ability to run directly from the console with ease.

[philipstarkey]

Original report (archived issue) by Ian B. Spielman (Bitbucket: Ian Spielman, GitHub: ispielma).

---

Currently the user is compelled to use GUI programs. It would be desirable if ALL the gui programs were simply talking to "server" processes that the user could directly send tasks to. Meaning the "blacs server" could run on a headless machine and the GUI could be anywhere.

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

Brain dump of my thoughts on this (at least the ones I can remember...now seems a good idea to write them down!)

• For BLACS we'll need a new event framework (like twisted? or similar?) I think, as we use the Qt GUI event loop as a way to ensure thread safety (by posting events back to the main thread).
• Do we allow only one or multiple clients to connect to the server? If multiple, how do we handle conflicts in GUI state.
• The classes (in blacs/output_classes.py) that handle the backend of widgets are tightly coupled to their widgets
• How do we handle the concept of "plugins" (currently undocumented but this is how the connection table recompilation is implemented) given that these are very GUI based, but will need to exist in both the client GUI and the server

[philipstarkey]

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

---

A first approach to this might be just to make lots of things scriptable without thinking too hard about getting rid of GUIs or managing multiple clients.

For example, runmanager is probably going to grow a 'remote' API for setting variables and submitting shots and whatever. Pretty much every API call would correspond to something the user could do in the GUI, but the function would be being called programatically instead of by button-click. If BLACS grew a similar API whereby you could call functions to pause the queue, set an output to a value, inspect whether any tabs have errors, and that sort of thing, and the other programs grew these things too, it would make the suite scriptable even though the GUIs were still there. You could write a script that would program something into the front panel of BLACS, add analysis routines to lyse and then tell runmanager to start submitting shots.

A sledgehammer way of "managing" the possibility of multiple clients is to allow a client to just take a lock on the "write" parts of the remote APIs - like setting a runmanager variable or setting a BLACS front panel value, and other clients would just have to wait or time out, and the GUI would grey out or something so the user couldn't click buttons and interfere. "get" methods like "what is the value of this global" or "what is the current front panel value set to" ought to still work, no reason they should be locked out. Your script would just acquire a lock for the entire set of operations it was doing, not just on a per-API-call basis.

Making the GUIs be 'just another client' is nice but quite ambitious I think, and allowing the GUI to continue to exist even if nobody is looking at, whist being remotely controllable would be most of the way there.

Qt can be headless, though. I think you just have to use a QCoreApplication instead of a QApplication.

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

Qt can be headless, yes, but I think there may be issues compiling Qt on some headless systems if they, for instance, don't have X11 or something like that. Seems like an odd choice to keep Qt on Python just for the event managing bits, but I guess we'll see how it evolves.

[philipstarkey]

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

---

Oh, I was just mentioning it, I am not attached to Qt for a headless program - I would keep it if it made porting easier by a big enough margin, but otherwise not. Our event loop needs, once there's no GUI are very modest, so I think many things would suffice. Python 3 even comes with its own event loop in the standard library nowadays I believe, it's possible that would do, but I'm not very familiar with it.