-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI scripting #68
Comments
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). |
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 |
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. |
Original comment by Russell Anderson (Bitbucket: rpanderson, GitHub: rpanderson).
|
Original comment by Russell Anderson (Bitbucket: rpanderson, GitHub: rpanderson). Awesome, Chris. Indeed, some of the clunkiness derived from not being able to enumerate |
Original comment by Russell Anderson (Bitbucket: rpanderson, GitHub: rpanderson).
|
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. |
Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
Implemented in pull request #37 |
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! |
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:
Additional features might include:
The text was updated successfully, but these errors were encountered: