BOR LC 7: LC Usability / Windowing
Phil Weinstein, CADSWES, 4-24-2017, initial writing in progress.

Objective

Investigate some type of improved window docking structure within RiverWare for better control of

• Open Object dialogs
• Open Slot dialogs, and
• RPL dialogs.

We may also want such a capability to be extendable to Plot Viewer and Editor dialogs.

Requirements Research Tasks

Any windowing management features need to both well support particular repeated workflows, and be general enough to accommodate a broader set of unknown workflows.

We need to define particular specific use cases these features are intended to support. A few specific use cases would be good, representing both ad-hoc window instance layouts and persistent window instance layouts. Questions that the use case descriptions should answer include:

• Is there a need to manage a homogeneous set of dialog types (only slots, only objects, only rules, etc).
• Is there a need to manage a heterogeneous set of dialog types? What groupings?
• What is the relationship between simultaneously shown dialogs?
• What one-shot reordering operations would be helpful, e.g. ordering slot dialogs by their upstream to downstream relationships, or the relative positions of their object icons on the workspace?
• For groupings that don't fit simultaneously on the screen, what "navigation" operations are needed?
• How many dialogs will be typical in a window grouping, and how many need to be simultaneously visible on a screen.

Available Technical Windowing Capabilities (Qt)

(1) QMainWindow / QDockWidgets

The QMainWindow class (of which many can simultaneously be shown -- the application is not limited to a single main window) provides a panel docking capability. Dockable panels need to be deployed as a QDockWidget instance, and don't support their own menubar. Like QMainWindow toolbars, dock windows can be dragged and snapped to any of the four sides of a QMainWindow, or can be torn out as their own window. Multiple QDockWidgets can be added to a single QDockArea, in which case tabs are automatically created in that area to switch between the different QDockWidgets. (Those possibilities can be limited by the application, e.g. it might be reasonable to dock a particular panel on the right or left side, but not the top or bottom). RiverWare makes use of QMainWindow QDockWidgets in only a few areas, the most promininant being a very simple use (single QDockWidget) for the Simulation Object List in the Workspace.

(2) Direct Control of Window Positions

With Qt on Windows we can precisely position and resize individual windows. (This was more difficult with the X Windows System on Unix/Linux platforms). Also we can receive window move events for any window. With these capabilities we can implement our own window management capabilities, e.g. for tiling and cascading windows.

Research

• Qt Best Practices: Restoring a Window's Geometry
  http://doc.qt.io/qt-5/restoring-geometry.html
  ... actually, we already do something like this. See calls to DlgGeometryMgr methods in showEvent() and hideEvent() overrides.
  
  
• Searching "Qt Window Manager" ...
  • "kwin" is actually an X Window System window manager, being ported to Wayland. These are Unix/Linux solutions. So, not likely applicable.
• StackOverflow.com post [2012] -- Not really applicable
  Is there a standardized way of managing windows in Qt applications?
  http://stackoverflow.com/questions/8695931/is-there-a-standardized-way-of-managing-windows-in-qt-applications