USACE ABQ 5.11: Output Canvas Items on Workspace views / Architectural Preparation

Project: USACE ABQ 5.11: Output Canvas Items on Workspace views
Phil, 4-09-2017 (a).

SEE also Phil's project reference webpage.

I've completed the architectural preparation for this project, and am ready to turn this over to Robynn. (See the CoeAbq5p11-OutCanv1 branch).

My important goals for this work were:

Breaking out the implementation of the OutputCanvasScene (a QGraphicsScene, in which all the visible QGraphicsItems live) into a delegated class which can be used by both the OutputCanvasScene and WorkspaceGfxScene classes. The new class is OutputCanvasGfxItemMgr (a QObject subclass).
Actually deploying an instance in each of the three WorkspaceGfxScenes (Simulation, Geospatial, and Accounting).
Quite a bit of QGraphicsItem life-cycle testing and fixing. (There were a few things that needed to be done). This seems good now.

This is in a very demo-able state. In a model having an Output Canvas (output device), the provisional new menu item, Workspace >> "Set Output Canvas...", shows an Output Canvas selector popup.

The picked Output Canvas is associated with the current RiverWare Workspace View.
Note however that canvas items (teacups and such) are currently using their Output Canvas coordinates -- which show up on the UPPER LEFT of the Simulation and Accounting Views (and god knows where in the Geospacial View).
This canvas objects are currently deployed on the Workspace in their "active" (configuration editor) state. So they can be dragged and resized, and Flow Lines can be edited (right in the workspace). For a DEMO, also show the Output Canvas VIEWER of the relevant Output Canvas, and play with the canvas items in the workspace -- including editing flow lines. (Robynn will need to hide the output canvas items which we don't currently intend to support in the workspace views).
An interesting consequence of deploying output canvas items in the workspace views is that they now support multiple-selection (by dragging a rectangle around multiple items) in the workspace.

POSSIBLE DESIGN CHANGE TO BE CONSIDERED:

Especially after playing with flow line editing in the workspace, I see that we might prefer to optionally associate a SINGLE Output Canvas instance with each of three Workspace Views. This would make coherent the showing of the Output Canvas rwSettingTree-based editor panel (which necessarily operates on a single OutputCanvasConfig instance) right within the workspace (momentarily, perhaps in place of the Workspace Object Treeview) to edit the output canvas items in the workspace. (I don't mean to suggest that this would need to be part of the current work). The thing is, limiting each workspace view to a single Output Canvas affords us a coherent path to such functionality. This might mean that the Workspace View / Output Canvas association is controlled by the user from the "workspace side" (as the current demo partially implements) instead of from the "output canvas side".

David -- I need to back-peddle on my idea that this machinery would very naturally support an arbitrary set of Output Canvas items (teacups and such). As it turns out, that would have required additional complexity which isn't currently required for USACE ABQ 5.11. The new OutputCanvasGfxItemMgr supports exactly one Output Canvas configuration instance (as did the OutputCanvasScene, from which the new class has been constructed). If we still do want to support Output Canvas items from multiple output canvases showing up in a workspace view, the WorkspaceGfxScene would support multiple OutputCanvasGfxItemMgr instances -- one for each OutputCanvasConfig instance, with a structure like this:

QMap<OutputCanvasConfig*,OutputCanvasGfxItemMgr*> _outCanItemMgrMap;
See the following section in QtUtils//WorkspaceGfxScene.hpp
... "Auxiliary QGraphicsScene management for Output Canvas Items".

Partial list of tasks still to be completed, presumably by Robynn, not necessarily in this order:

Workspace coordinate systems for Output Canvas items, including initial positioning of items in those coordinates. This is a pretty large task. The Geospatial View (the primary requirement) poses some special challenges -- including proper scaling of the internal graphical measurements. (Good luck!). (This needs more discussion -- we can consider applying Qt geometric transforms to individual QGraphicsItems).
Design and implement the Workspace View / Output Canvas association, with persistence. (See the "possible design change to be considered", above).
Provide a workspace-based reference Date_Time to Output Canvas items. (See mention of the relevant hook below).
Hide output canvas item types (from the workspace) which we don't intend to currently support.
Correctly condition the move-ability (and resizing) of items with the workspace's "Lock/Unlock Icon Positions" toggle.
Optional (TBD): Support the output canvas items' "Configure..." context menu operation -- bringing up the Output Canvas' editor with the correct item selected. (See mention of the relevant hook below).

The following application hooks are available for Robynn's coding:

A way for the workspace to provide an "override" reference Date_Time for the Output Canvas items. See method: WorkspaceGfxScene::gfxItemMgr_retrieveClientDateTimeOverride (Date_Time&);
A notification from canvas item's "Configure..." context menu item. The Workspace could bring up the relevant Output Canvas' editor dialog and cause the configuration item to be selected (showing that canvas item's setting in the rwSettingTree). See method:
WorkspaceGfxScene::gfxItemMgr_configureNodeRequest (OutputCanvasNode*, int& processedCnt);

-----

Issue: Some QPixmap Problems Reported:

The following sorts of errors are being generated to the system console. I am also seeing them in 7.0.6, but I do see more of them in new 7.1 development. (This may be evidience that it is associated with the resize-anchor points -- that's just a guess).

QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::setOpacity: Painter not active QPixmap::scaled: Pixmap is a null pixmap QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::setOpacity: Painter not active QPixmap::scaled: Pixmap is a null pixmap QPixmap::scaled: Pixmap is a null pixmap QPixmap::scaled: Pixmap is a null pixmap QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::setOpacity: Painter not active QPixmap::scaled: Pixmap is a null pixmap QPixmap::scaled: Pixmap is a null pixmap

---