UI scripting

[philipstarkey]

Original report (archived issue) by Russell Anderson (Bitbucket: rpanderson, GitHub: rpanderson).

---

... does what it says on the packet (get it?). Main use case is algorithmic optimisation, including from a lyse analysis script.

Minimal features include:

1. Setting the value of particular global variables (with the specification of which global variable(s) to change done script-side).
2. Pressing the Engage button (shot compilation).
3. Locking some/all elements of the UI for some duration, e.g. while these global variables are being changed.

Additional features might include:

1. A new column in the tree- or table-view to enable/disable globals from being remotely altered.
2. A top-level control to enable/disable any remote control.
3. Some indication of whether a global is being (or has been) remotely changed. This could be at the per-variable or whole-UI level. If this were to happen more than transiently, there'll need to be the concept of a remote control session. This is inextricably linked to minimal feature 3, i.e. whether remote control should lock the entire UI (reminiscent of SCPI programming of test equipment), which in turn dictates the type of control element used for additional feature 2.

[philipstarkey]

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

---

Longer term, I'd be inclined to split the runmanager GUI away from the underlying framework that manages globals (and globals files). I suspect that's a more appropriate architecture for distributed global management (which is effectively what this proposal is).

[philipstarkey]

Original comment by Russell Anderson (Bitbucket: rpanderson, GitHub: rpanderson).

---

Better distributed global management may well be a longer term goal, but it's different to the scope of this pull request. In the Monash Spinor Lab in 2018 we used runmanager library functions for this, calling runmanager.set_value and runmanager.compile_labscript_with_globals_files_async, with the callback of the latter submitting compiled shots to blacs. This was clunky and had some limitations, not least owing to globals being able to exist non-uniquely across multiple files, with the arbiter being the 'active' state of a globals group.

[philipstarkey]

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

---

I'm somewhat likely to be working on this in the next couple of weeks, as automated optimisation is happening in our labs. Will aim for the above minimal features and take it from there. Anyone else should feel free to work on it too, but maybe check with me if I've started on it yet so that we're not doubling up.

The runmanager API is clunky, but I think the clunkiness comes from there being no global state as to which globals groups are currently active and that sort of thing. This state is presently stored in the runmanager GUI (and saved to disk upon quitting), which is why GUI scripting is appealing, since then the script doesn't need to provide that state. But if runmanager were a GUIless program holding that state, or perhaps if the state were stored on disk and changes to it were scriptable without runmanger actually running, then I think that's more what phil is getting at. But I also think some of these more lofty goals should be considered pretty low priority, since in practice having to run a GUI program as a server (once it is scriptable) would not be preventing anyone from doing anything they need to do.

[philipstarkey]

Original comment by Russell Anderson (Bitbucket: rpanderson, GitHub: rpanderson).

---

• Edited issue description

[philipstarkey]

Original comment by Russell Anderson (Bitbucket: rpanderson, GitHub: rpanderson).

---

Awesome, Chris.

Indeed, some of the clunkiness derived from not being able to enumerate
active groups remotely. We worked around this using a specific compiled
shot file as a template, as it contained the active globals groups in a
single h5 file. Calls to set_value modified this file (or a copy of it),
and subsequent shot compilation created shot files wth the same base name
as the template, but with some repeat-like alias/number.

[philipstarkey]

Original comment by Russell Anderson (Bitbucket: rpanderson, GitHub: rpanderson).

---

• Edited issue description

[philipstarkey]

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

---

Regarding locking the GUI: The remote functions I've implemented in pull request #37 can set multiple globals at once, and do so in the main thread of runmanager, so that is not interruptable by user action. Acquiring a lock on the GUI would still be useful if you were wanting to get, set, and engage all in a row without being interrupted, is that the sort of thinking you had in mind? I wonder if this is of limited usefulness and if a 'we are all adults here, it is up to you whether to mess with runmanager during optimisation' attitude might be ok.

[philipstarkey]

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

---

• changed state from "new" to "resolved"

Implemented in pull request #37

[philipstarkey]

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

---

The remote scripting that has been implemented could be made nicer, such as having a record of previously set values so that remote setting doesn't just erase existing value unrecoverably, but this will all require some thought. Closing this for now!