Requirements Analysis for a RiverWare Slot Viewer, Bake 1
Phil Weinstein, CADSWES, 7-14-2017 (b), SUPERSEDED. See Bake 2.
As a way to improve the manageability of windows in RiverWare for which many window instances are commonly used, the introduction of the Object Viewer in RiverWare 7.1 (released just this week) seems to be very successful. We are now pursuing a similarly inspired approach for Series Slots (perhaps with support also for Scalar Slots and display-only support for Periodic Slots), presenting multiple Slots in a single dialog, in a tabular presentation similar to the Edit Account dialog.
The Object Viewer is devised strictly as an "ad-hoc" tool. Objects are added to the Object Viewer (as Object Tabs) every time an Object is opened. The list of objects in the Object Viewer has no persistence. We want the Slot Viewer to similarly support "ad-hoc" operation, rather than something requiring a lot of (or really, any) set up. Each time a Series Slot is opened from anywhere in RiverWare, it is just added -- as a column, or multiple columns -- to the Slot Viewer. From the Slot Viewer, any slot can then be shown also in (or perhaps, instead in) the slot's conventional Open Slot dialog.
Potential requirements for the Slot Viewer need to be addressed in ways which are compatible with ad-hoc operation. A potential conflict which comes to mind is the requested provision for swapping in a different object for the Slot Viewer's slots. It's not hard to imagine work flows in which we would want such an operation to apply to only certain slots in the viewer. We might want to implement flags on slot items to indicate their participation in this operation. We can entertain some settings like this, but such provisions need to be evaluated in the context of the general ad-hoc use of the Slot Viewer.
Important Functional Requirements:
Other Provisions to be considered:
(*) Display-only support for Periodic Slots as interpolated (or stepped) values within a series display might be a valuable SCT enhancement. (However, the SCT's series data display is implemented with different C++ classes).
(**) Although support for Table Series Slot columns may not be an important requirement, the existing C++ classes used to implement the Slot Viewer do readily support those.
Reconsidered Prior Requirements:
A prior analysis from late April suggested the following provisions:
These drag operations interfere with the use of dragging along the column header to select multiple selected slots (display columns). Selection of whole slots in this manner is important for many operations on slots we need to support. We will support slot reordering
and the showing of separate Open Slot dialogs in other ways.
REVISION (7-15-2017): We can actually use DRAGGING a display column header to show the Slot's Open Slot dialog -- and also dragging the Open Slot dialog's icon (or something) back into the Slot Viewer. Those GUI operations would not interfere with dragging along the column headers to select contiguous slots. (This would be implemented with low level mouse events, not Qt drag events, as such).
The Slot Viewer will present most of the conventional Open Slot Dialog controls above the series data table. This includes:
Above those legacy controls will be new controls for operating on the set of slots shown in the Slot Viewer. Here is one possible design:
The "Slots" combobox would be populated with only the timestep sized actually represented by Series Slots actually present within the Slot Viewer.
A treeview button shows a second row of controls. Depicted above are controls for these operations:
Operations dependent on the current Slot selection would be dynamically conditioned (enabled/disabled) based on the current Slot selection (whole selected display columns).
There are many ways in which the Object of slots in the Slot Viewer could be swapped out with a different Object. Since this is the ad-hoc tool where ALL series slots are shown immediately when they are "opened", and we are not saving named Slot Viewer configurations, this feature shouldn't incorporate a lot of setup.
A "Change Object" Operation requires two general inputs:
(A) The Object could be identified in these ways:
(B) The Slots could be identified in these ways:
The following mockup (on the right side) demonstrates the "Wildcard Object" Slot Item design (B3) where particular Slot Items are identified as "Wildcard Object" Slots. Those would be indicated with a some sort of ornamentation in the column header (e.g. a cyan background, matching the color of the "Set Obj Wildcard" button). This supports both the (A1) "Object currently shown in the Object Viewer" and (A3) "One of several objects in a small list of object names maintained in the Slot View" (and persistent in the model file).
Many of the series data displays in RiverWare -- but not the SCT -- are implemented with a common set of classes -- a dialog class (SlotQtDlg, with four different application modes) and a series data table class (SlotDataTableView, a QTableView subclass, with supporting data model and delegate classes). The four "applications" are:
Once the array of Slots (actually, of Slot Column References) is set up within the series data table's QAbstractTableModel subclass, much of the operation of these classes, e.g. displaying and editing series slot values, and support for the "selection statistics", is independent of the particular application.
The Edit Account application is basically the closest to what's required for the Slot Viewer. But the Object Account Summary application has some dynamic provisions which are also relevant, dynamically installing a new list of slots based on names from two different lists: Accounts on an Object, and the names of Series Slots on Accounts.
The Slot Viewer would be fifth application of these classes. Work to implement this application includes supporting widget and menu creation and layout within SlotQtDlg, and algorithms to build the Slot Column Reference (SlotColRef) list within the series data table model class. An alternative to extending SlotQtDlg with a new application is creating a new dialog class which makes use of the series data table class. That approach should also be considered. In fact, that sort of thing was done recently by Patrick Lynn for the RiverWare Scenario Explorer.
--- (end) ---