More standard saving and loading of globals from h5 files, file changed on disk detection

Original report (archived issue) by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

When I first write runmanager, globals were written to the HDF5 file on every keystroke. Now they are written when you finish editing a cell.

I propose to further demote this to only saving when prompted. You know, the way normal applications work where data is unsaved until you save it.

The main benefit of this is being able to muck with globals willy-nilly without fearing breaking things, because you can just revert, or not save on exit.

It would not even be hard to implement. On file-open, runmanager would make a copy of the file in a temporary directory. The user would edit globals on a per-group basis, which would display an asterisk or some other visual indication that they were unsaved. There would be a menu item and keyboard shortcut to save the currently visible group, and you would be prompted to save a group upon closing. Upon saving a group, that group would be copied over to the actual file, from the temporary file.

Runmanager would allow you to run shots when globals were unsaved. This is safe because it is not a pointer to the globals files that is stored in the shot files, it is the globals themselves. So there is seemingly no benefit to forcing the user to save globals before compiling.

You would also be able to 'save as'.

When another process changes the original h5 file on disk, the user should be able to choose whether to abandon their changes and reload groups from the file, or overwrite the changes. Like other programs that do this, we would not provide indication of what has changed.

labscript-suite / runmanager

More standard saving and loading of globals from h5 files, file changed on disk detection #27