BOR LC 7: LC Usability / Windowing / Open Obj Panel in Workspace
Phil Weinstein, David Neumann, Edie Zagona, CADSWES, 5-01-2017, Notes.

See prior general notes:

ADDENDUM: Open Object Panel in Workspace

As an alternative to the Open Object Viewer as described in the prior notes, we would also like to consider an alternative of deploying an Open Object Panel within the Workspace dialog. Here is a mockup:

These notes explore one particular challenge with this arrangement: Reconciling the Open Object Dialog's MENU BAR with that of the Workspace.

One thing that I tried was use of the Qt 5.5.1 QMenuBar::addSeparator() method, to see if that would make the subsequently added menus to be right-aligned in the menubar (or otherwise, visually separated). This method has an effect only in certain Qt widget styles, and apparently not for any of the three available "Windows" widget styles, nor with the "Fusion" style.

While QMenuBar is a QWidget which could be deployed at the top of any panel widget, QMainWindows support only a single QMenuBar. FWIW, When using a QMainWindow, we don't have to use that QMainWindow's automatically created QMenuBar -- we can provide our own instance (e.g. a QMenuBar subclass). (I don't mean to suggest that that will be helpful to us here).

We would have basically two choices:

  1. Deploy the Open Object Panel's QMenus (or, in some way, those QMenu's QActions) in the QMainWindow's QMenuBar. This seems very problematic; the ensuing complexity and confusion would be prohibitive -- especially being that we can't push the latter menus to the right side of the menubar (as mentioned above).
  2. Deploy the Open Object Panel's QMenus in a secondary QMenuBar (at the top of that panel), and either technically address, or live with the limitations that QMenuBar not being coupled with the QMainWindow.

Secondary QMenuBar Issues:

  1. Shortcuts would probably not be active in the secondary QMenuBar. We would probably have to take over the implementation of those at the QKeyEvent or QEvent handling level.
  2. We would have to resolve any conflicts between uses of shortcuts from the two dialogs (Workspace and Open Object Dialog).
  3. Key navigation through the menu items. On windows, pressing the Alt key when a QMainWindow has focus causes its QMenuBar to receive keyboard input focus. The first menu becomes armed, underscore characters appear on letter-based shortcuts (e.g. "F" for "File"), and the user can use the arrow buttons to navigate through the actions in the menu. If the secondary QMenuBar doesn't automagically participate in this keyboard navigation (which sees unlikely to be supported), there probably isn't anything we can do about that.

Reference -- Workspace Dialog Shortcuts: 

 _openModelAction        -> setShortcut (Qt::CTRL + Qt::Key_O);
 _saveModelAction        -> setShortcut (Qt::CTRL + Qt::Key_S);
 _saveAsModelAction      -> setShortcut (Qt::CTRL + Qt::SHIFT + Qt::Key_S);
 _exitAction             -> setShortcut (Qt::CTRL + Qt::Key_Q);
 _runControlAction       -> setShortcut (Qt::CTRL + Qt::Key_R);
 _mrmControlAction       -> setShortcut (Qt::CTRL + Qt::Key_M);
 _evalExprSlotAction     -> setShortcut (Qt::CTRL + Qt::SHIFT + Qt::Key_E);
 _validateExprSlotAction -> setShortcut (Qt::CTRL + Qt::SHIFT + Qt::Key_V);
 _deleteObjectsAction    -> setShortcut (Qt::Key_Delete);

Reference -- Open Object Dialog Shortcuts (slightly different syntax): 

 _copySlotsAction    -> setShortcut (tr ("Ctrl+C"));
 _pasteSlotsAction   -> setShortcut (tr ("Ctrl+V"));  // partial conflict (shifted)
 _closeAction        -> setShortcut (tr ("Ctrl+W"));
 _slotsViewAction    -> setShortcut (tr ("Ctrl+S"));  // conflict
 _methodsViewAction  -> setShortcut (tr ("Ctrl+M"));  // conflict
 _accountsViewAction -> setShortcut (tr ("Ctrl+A"));
 _openSlotsAction    -> setShortcut (tr ("Ctrl+O"));  // conflict
 _plotSlotAction     -> setShortcut (tr ("Ctrl+P"));

Reference -- Workspace Menus:

Reference -- Open Object Dialog Menus:

--- (end) ---