|
|
# How Views Could Work in SMTK 2.0
|
|
|
|
|
|
In the Wiki page (https://gitlab.kitware.com/cmb/smtk/wikis/Improving_Attribute_GUI_Creating) we discussed the possibility of providing a lower level approach for implementing Views that included the ability to explicitly specify widgets such as Frames as well as layouts such a Form, Grid, and Table. Though I think the ideas make sense, there is still a question as to how widgets related to items get properly placed in the View. In particularly the following cases need special attention:
|
|
|
|
|
|
1. The item has multiple values such as a vector of ints
|
|
|
1. Case where the values have unique labels
|
|
|
2. Case where the values have a common label
|
|
|
3. Case where the values have no label
|
|
|
2. The item has optional childern
|
|
|
3. The item is a group
|
|
|
|
|
|
As in the current design the idea is to have the Qt View be in control of how the GUI is created. The specific qtView object dictates how the information stored in the common View structure is interpreted. The figure below shows how things work in SMTK 1.x
|
|
|
|
|
|
![SMTK1.xqtView](/uploads/6411101e0d17deee6c1a3ba656b644e3/SMTK1.xqtView.png)
|
|
|
|
|
|
The main differences from the 1.x design include:
|
|
|
|
|
|
* The View does not delegate control to the qtAttribute class
|
|
|
* Group Views are not simply Vertical Layouts
|
|
|
* UI Manager will also be a factory for the widgets for Attribute Items
|
|
|
* As in the case of Views, GUI Item constructor functions are registered to the UI Manager
|
|
|
|
|
|
The figure below shows the proposed architecture for 2.x. Note that the qtAttribute class is not depicted. It has not yet been decided if the class will be removed but it's role will definitely be reduced.
|
|
|
|
|
|
![SMTK2.xqtView](/uploads/fb7e6d14bf422dc05cc36388d3e7e5fe/SMTK2.xqtView.png)
|
|
|
|
|
|
The idea of an Item Specification would allow greater control as to how the item is to be rendered. For example, in the case of a group item whose components are easily comprehended such as time the individual labels can be omitted. In addition, the designer could indicate a custom widget to be used. For example if the 3 tuple double item represents a point in space then the specification could indicate a PointWidget should be used. The specification would include the following information:
|
|
|
|
|
|
* Reference to a common::View::Component that comes from the View Specification
|
|
|
* The current last widget in the tab/focus chain - this would be used to control tab ordering
|
|
|
|
|
|
Note that the parent widget for the item is not included. Instead of the item inserting its widgets into the parent's layout, the widget (or widgets) are returned and the View will insert then into the layout. In this way the item widget does not need to know what are all the possible layouts that can exist.
|
|
|
|
|
|
What the UI Manager returns is the following:
|
|
|
|
|
|
* The set of widgets to be inserted
|
|
|
* The last widget in the tab/focus chain |
|
|
\ No newline at end of file |