Feature Abstract: Workspace Object Aggregation is a new capability of the RiverWare Workspace which allows arbitrary sets of simulation objects to appear on the workspace as a single icon. (See Phil's analysis document).
Re: Object Group context menus ... Edie added: "This is an extensive menu. It should probably also be in the menu bar."
Below is a screenshot of the current Workspace >> Object submenu. We could add a "Workspace >> Object Groups" submenu for operations to be applied to the selected Object Group icons.
[#8] "Each Object Group will have two display states" ... Here are some alternatives:
[Question EAZ3]: "What is the current context menu for a selected set of objects?"
When several simulation object icons are selected, the context menu on any of those selected objects changes. Some, but not all of the operations are changed to apply to the full set of selected objects -- and that change is reflected in the context menu operation text ...
[#1] Create Object Group: context menu operation on the workspace. All currently selected objects are made members of the group. Selected objects which are a member of another group are quietly removed from that other group.
[EAZ2]: Maybe not quietly
... agreed. A confirmation dialog can be shown if any of the selected objects are already in an object group.[New comment from Phil] ... There is a functional complication with implementing "Create Object Group" as a context menu on the workspace: clicking on the workspace deselects all simulation object icons. Even though we could "capture" that set of object icons, it will be somewhat astonishing to the user for that to work. We might instead include a <New Group> item to the simulation object's Add Object to Group context menu submenu.
[#3] Add Object to Group. This could be implemented with either or both:
(a) dragging an object icon over to an object group icon.
(b) context menu operation on simulation objects ... submenu of object groups.
[EAZ4]: (a: dragging) is not a good option because the objects are intended to maintain a position on the workspace that they will take when objects are "expanded".
[Phil's response]: I agree with the decision to not implement dragging for this. Although my intention was that "dropping" an object icon onto an Object Group icon would not effect the object's original position, IF the user "missed" the Object Group icon (i.e. released the mouse when it wasn't quite over the Object Group icon), the user would indeed be changing the object's position (by mistake).
Edie added items (5) (6) and (7), the latter two regarding having Object Groups show up as items the Workspace Object List:
[Phil's response to #7]: Without introducing an additional "highlighted, but not selected" implementation for Workspace graphics objects, the implication of highlighting a (collapsed) Object Group icon when any of its member objects are selected within the Workspace Object List is that ALL member simulation objects of the group will become selected. However, the Workspace Object List simulation object item context menu doesn't currently support any operations which would be effected by this. So there is no problem with adopting Edie's proposed (#7) -- but it would have the effect of selecting all of its "sibling" object list items -- that is, unless we introduce a new "highlighted, but not selected" state (a day or two of extra development).
[EAZ5]: Why?
[EAZ7]: Omit these.
Certainly let's omit these. But FWIW, the rationale is that, just looking at the workspace, it might be a little confounding to not know if an Object Group's member object's icons are among those that are currently visible on the workspace -- that is, "Is that Object Group expanded or not?". Also, it might be nice to have an easy way of quickly, graphically inspecting which icons are a member of an (expanded) group. Neither of these features are essential.
Edie added this sentence: Opening the group should show the list of objects; selecting one will open the object.
Question: Is this intended to indicate what the "Open Object Group Dialog" would look like if we did implement it? Or is this a suggestion that we should actually provide this dialog box?
Because of the context of Edie's added note, "Should operate in Geospatial," it's not clear to me that this also means that Object Group "Scope" should be global rather than specific to the Workspace (Simulation vs. Geospatial) in which the group was created.
BTW, I think I am now favoring the "global" scope idea, but the expanded/collapsed states should be distinct in the two workspaces. That is, it should be possible to have a particular Object Group expanded in one of the two workspaces, and collapsed in the other.
--- (end) ---