Phil's status summary and current recommendations. (See details in subsequent table).
| Review item (see below). |
Status |
Action |
| 7 |
Order menu left margin |
DONE |
Addressed with a QStyle change to the popup menu. See images. |
| 8 |
Re-orderable columns |
--- |
We'll keep the columns non-draggable. |
| 9 |
Remove old menu operations |
DONE |
(minor) |
| 10 |
Controller-based slot filtering |
DONE |
Controller-based filtering REMOVED. |
| 11 |
Polymorphic custom obj type orderings |
--- |
Decision: No change for now. Consider as subsequent modification. |
| 12 |
Set order mode for all objects |
--- |
Not done. To a limited extent, the new initial-order algorithm addresses the basic requirement. |
| 13 |
Confirmation dialog text |
DONE |
|
| 14 |
Slot type ordering |
DONE |
(1) defined a more meaningful order.
(2) BUT: did NOT add support for reversing the order. |
| 15 |
Custom Object Type Slot Order editing |
DONE |
Disabled edits (with up and down arrows) to the "Custom for Object Type" order. |
 |
|
|
| 7 |
| In my window manager, the two order menus have a big left margin column, presumably for icons. Are these used for anything? If not, can we get rid of the column. |
|
 |
|
| |
|
Two non-perfect solutions have been found.
- [Using QStyle]: If available, the "CDE" or "Motif" style is applied to the menus. Their appearance
is OK, but not great. And they lack dynamic "hover" ornamentation.
- [Using QStyleSheet]: Assigning a style sheet property to the QMenu seems to
disable the "Windows 7" style, so the margin is reduced from about 35 pixels to 18 pixels.
But that style sheet code doesn't actually seem to be functioning -- changing the width
property has no effect.
|
| 8 |
Here's another thing we should decide on. In the previous implementation, you could re-order columns. Now you cannot. Do we want to support that? My vote would be No, but I don't have a strong opinion. |
| |
(The re-ordering David mentions was accomplished by "dragging" column headers).
I also recommend that we not support column re-ordering. If it was desired, I'll have to determine if any code changes are needed in response to enabling column dragging.
[Edie confirms that we should skip this, i.e. not have draggable columns] |
| 9 |
We should remove the View->Save Obect-Type Sort Order. This is no longer applicable and would be confusing. |
| |
Yes. (See the following image). |
| 10 |
What about the View->"Show Slots for" menu. Aren't we going to put that in the Filter Slots section?
|
| |
I believe we had decided that we would reexamine this issue after this work. If I understood correctly, Tim (whose "optimization" workflow involves switching between controllers) mentioned that this wasn't even a useful feature, and we should just remove this filter.
If would kinda hate to complicate the new user-controlled filtering controls with something which isn't important.
[Edie requests that controller-based filtering be removed]. |
| 11 |
Save for Object Type should treat Storage, Level, Slope, Pumped, all as Reservoirs. They are the same to the user at least at this level. |
| |
Polymorphic treatment of reservoirs would require a reworking of the persistent slot ordering data model. The current functionality -- distinct Object Type-level orderings each concrete object type -- matches what is provided in prior (RW 6.2) implementation.
[Edie confirms that this can be considered later, as a subsequent modification]. |
| 12 |
Is there a way to say "Show Custom for Object Type" for all object. You shouldn't have to go to each object and choose "Custom for Type". There is an analogous "Apply Filter to all..". |
| |
For now, we regard this requirement as partially addressed with the new initial order mode algorithm. When an Open Object Dialog is shown, the initial order mode will be:
- Custom for this Object, if there is one. Otherwise:
- Custom for Object Type, if there is one. Otherwise:
- Default order (hard coded for the Object Type).
... so note that the choice of slot Order Mode / Sorting of an Open Object Dialog for an object is not preserved in between uses. The slot order is always initialized using the algorithm above. |
| 13 |
The message "Do you want to save the current slot display order as the custom order for this simulation object type" should say the type, Reservoir, Reach... That would make it clear what it will apply to. |
| |
Done, for example ...
|
| 14 |
There is no way to sort by Slot Type except with ascending order. What is the order. I added a bunch to a data obj and it did Agg, Periodic, Scalar, Integer Indexed Series, MassBal, Series, TimeAgg, Table. That seems odd. |
| |
The right-hand image shows the revised slot order (based on IconHandle IconIDs). |
UPDATE: A revised order has been implemented -- based on IconHandle IconIDs. See the right-side image above.
Note that, apart from not being able to reverse this order, it is
I recommend that we stick with the current implementation of just one (nonreversible) order. I don't think supporting TWO items in the Order combo box for Slot Type ordering is warranted, e.g. ...
- Sort by Slot Type
- Sort by Slot Type (Reversed)
The alternative of breaking out the slot type icons as a distinct column is problematic for the multiple-level treeview modes of the slot list (for Aggregate Objects, and for slots shown under methods). |
| 15 |
If you have two objects of the same type open, both set to Custom for Object Type, and you move a slot up or down in one dialog, it moves it in the other dialog, without doing a Save.
It was not what I was expecting, but may be OK. It seems like once you move a slot, it should switch to some unsaved state and only change the other dialog when I choose "Save displayed order as..". Same with Custom for this Object. Should it preserve the state if I don't say Save As? |
| |
Note: The image previously shown (in yesterday's e-mail) didn't reflect a final change made yesterday which, in a small way, clarifies the current implementation: The "Save ... as" option corresponding to the current order mode is disabled ...
The concern for unintended changes to an Object-Type based custom slot ordering was addressed by disabling order changes (up and down arrows) when in "Custom for Object Type" mode. ALL slot reordering is now done in "Custom for this Object". The user can save that off as "Custom for Object Type" -- as in the old (RW 6.2) implementation.
|
