Gui ideas

[kakwok]

There were some ideas from the run meeting when the new GUI is presented:
https://indico.cern.ch/event/682469/contributions/2796834/attachments/1561573/2458690/NewGuiGuide.pdf
Just to note these ideas down and we can discuss:

1. CopyToClipBoard button for quick info. The runInfo header (config name, runkey, run number) already contains most of the info contained in QuickInfo. We could consider to replace the mono-space line with a CopyToClipBoard button.
2. Swap the order of Set and AutoConfigure
3. If we have AutoConfigure, why not AutoStart or TakeRun?
   Since configuring takes longer time, user dropping connection after clicking the auto button might happen more often

[jhakala]

1. CopyToClipBoard button for quick info. The runInfo header (config name, runkey, run number) already contains most of the info contained in QuickInfo. We could consider to replace the mono-space line with a CopyToClipBoard button.

It looks to me that in order to do this, it would require some hacky/bloaty javascript, so I'd rather
avoid that.

2. Swap the order of Set and AutoConfigure

Can do.

3. If we have AutoConfigure, why not AutoStart or TakeRun?

This could be done but I'd like to brainstorm how best to expand the automation functionality. Right now we have a special BoolT FM parameter for EXIT and AUTOCONFIGURE, so instead of making more and more special parameters, we could devise an all-purpose automation parameter. I am thinking the best solution is to replace the current automation parameters with a MapT that specifies a map of {state: command} to carry out automatically, i.e. an automatic start could be encoded as:

{  "Initial": "Initialize",
   "Halted": "Configure", 
   "Configured": "Start"
}

My first thoughts are that that format would make it a lot easier to define new automated actions in the future; e.g. one would not have to give a special name to a sequence of actions and implement it specifically; instead one would either:
a) put the exact JSON for a series of steps into the GUI code, and handle it there, or
b) abstract it out of the GUI a bit; instead, have the GUI send e.g. a StringT AUTOSTART over to the server side, and then the FM server-side code can populate the correct series of actions into the JSON parameter. That way the GUI code could be less in charge of defining the sequences for a particular routine. [This solution would probably mean creating two new parameters, the MapT that specifices the actions (populated on the server side), plus a StringT that the GUI populates for the GUI to send over to the server-side--it would read the StringT and then populate the MapT of actions.]

Since configuring takes longer time, user dropping connection after clicking the auto button might happen more often

A user dropping the connection is not all that bad; as soon as they reattach or another user takes control then it should proceed as normal.

[kakwok]

Adding one point:
4. Add a link to the mastersnippet file in cfg CVS from the runkey name

[jhakala]

Closing this -- I've split each item into its own issue.

[jhakala]

Just a note, I ended up doing the copypaste button in #392, so I'll remove the "superseded" tag.