BOY, mostly: Rethink Perspectives/Compact Mode/…, use Views for runtime (Lead: Kay - Reviewers: Kunal, Eric)

[kasemir]

Goal is to be able to “save” the layout of *.opi displays, so it can be “restored” and operators can switch between different layouts.
Maybe including a “frozen” mode where a “restored” layout cannot be altered.
Ideas (unclear if this is the solution):
OPI Runtime always based on “View”, and “Perspective” is used to save/restore.
Update compact mode to be more compact (hide status bar, …).

This should help with #457, #438, #101

[kasemir]

Some clarification what I think this is about:

Users want to save and restore the layout of *.opi panels on the screen.
As an example, the current layout may be called "Vacuum". "VacPumps.opi" and "VacValves.opi" are open in some arrangement on the screen.
Then operators can switch to a "Cooling" layout that instead opens "WaterPumps.opi" and "WaterTemperatures.opi" in some other arrangement on the screen.
Operators can switch between the two layouts.

I still think that these layouts can just be the RCP Perspectives, as also suggested by #438. Changing the opibuilder.Runtime to exclusively use "Views" instead of "Editors", and fixing how those "Views" keep their *.opi file path (#674) should mostly get us there. Unclear if perspectives would be configured by adding some new XML format file reader as per #438, or we study how perspectives are currently persisted and somehow create those files, or only use "Save As" and then copy the persisted perspectives from a development computer to the control room.

"Frozen" has been brought up in that operators should not be allowed to move things around or close windows. The RCP API for the Perspective offers IPageLayouts.setFixed(true), but that actually no longer functions in E4 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=331402). Realistically, I consider this a weak requirement. EDM etc. never prevented window movement. The web or email browser in which you read this can be moved. Operators will certainly need to open a Data Browser, start a logbook entry, maybe move windows around to better see what they need to see.
A more realistic requirement is a "Reset": In case operators moved windows or for example closed the "WaterPumps.opi", a "Reset" of the "Cooling" perspective should restore it to the original layout, re-opening the "WaterPumps.opi". Fundamentally, perspectives already support "Reset", so that should not be a technical problem.

[berryma4]

related to #438

[kasemir]

Notes from hangout today with FRIB, BNL, DLS, SESAME, ITER, SNS.

SNS:
See http://ics-web.sns.ornl.gov/kasemir/CSS_OPI_Views2.ppt.
All OPIRuntimes in RCP View.
Can use RCP Perspective to switch View arrangements.
Includes all Views (Probe, Properties, ..).
Excludes partstack "org.eclipse.ui.editorss".

DLS:
All OPIRuntimes in top-level SWT Shell.
Running inside CSS, with usual context menu for PVs etc.
External tools can use --launcher.openFile to open these OPIRuntimes.
Since they're top-level shells, Linux/X11 tools can be used to locate them based on their window title and adjust their position.
(Related: DLS branch implemented #104 for local files)

SESAME:
See http://www.aps.anl.gov/epics/meetings/2014-10/presentations/Wednesday/Fall%202014%20EPICS%20Collaboration%20meeting_Ibrahim%20Saleh.pdf pages 12, 13.
All OPIRuntimes in standalone Eclipse Window, compact mode.
Compared to DLS, this adds the 'tab' for the single part within the window. Could display multiple tabs within a window, but don't really want to do that.
Added mechanism to load/save "Profiles": Iterates over all Shells in the workspace, identifies those which contain OPIRuntime, saves their *.opi path and macros. On restore, restores those that were saved and closed those which happen to be open but are not included in the saved profile.
Using CSS in "Development" or "Runtime" mode. Same CSS binary, but runtime mode closes/hides the main Eclipse workspace window, so end users only see the standalone Eclipse Windows with the compact-mode OPIRuntimes.