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:
The item has multiple values such as a vector of ints
Case where the values have unique labels
Case where the values have a common label
Case where the values have no label
The item has optional children
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
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.
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
A reference to the qtItem Manager itself (this could be the UI Manager assuming its the object that deals with registering the Item Widget Factory Objects
We could implement this mechanism either as a static method to an Item Widget Factory class or as an Item Widget Factory Instance
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 vector of widgets to be inserted
A correspondening vector of string labels - this is needed since the View and not the factory places the widgets into the container widget. This isolates the item factory for having to deal with the various types of layouts that could be supported.
The last widget in the tab/focus chain
For an Instanced View, SMTK 1.x has the following format:
Label information is moved out of the Item Definition and Placed in the Specification which seems to make more sense
Pattern="*" is a shortcut to refer to all child items of the attribute (in their order given by the attribute). This may cause issues with the advance level — did you mean all items or only non-advanced ones. Also, "advance level" may disappear from attributes in the future since it is a markup.
Style=Spatial3D" refers to a specific Item Widget Factory. In this case this factory creates a Widget that is tied to a 3D Point Widget in the Spatial Views. If Style is not specified then the Basic Item Widget Factory based on the Item Type is used. For example Name uses DefaultStringItemWidget - Note that the Factory for generating the GUI for the View could override these defaults when processing its components. Use cases that may require extensions down the road include:
When GUI widgets (3d or otherwise) present more or fewer values than an item accepts/requires. An example would be color, where a GUI may only provide 3 values (HSL) while the item may want 4 values (HSL+alpha). Similarly, a GUI widget might provide RGBA values for color where an item only wants RGB.
It is possible that multiple items will want to share a single GUI widget (3d or otherwise).
Additional Information can now be specified - for example setting the length for the Name Item
When an Item has the possibility of generating multiple widgets based on having children items or multiple values, there needs to be an option to control if a single or multiple widgets would be returned.
In the case of processing Group Items - it should be possible to indicate if its children should be returned so they could be placed in the parent's container widget: