... | ... | @@ -106,9 +106,90 @@ In terms of Widget Types, an initial list could be: |
|
|
* TabWidget
|
|
|
* Collapsible Group Box
|
|
|
|
|
|
New Item attributes
|
|
|
* How big to make text
|
|
|
* Specifying Color for widgets, attributes, and items.
|
|
|
# Updated Proposed Version
|
|
|
Based on feedback from several developers the following is the current proposed View Format:
|
|
|
|
|
|
```xml
|
|
|
<Views>
|
|
|
<View Type="Group" Title="SimBuilder" TopLevel="true">
|
|
|
<!-- Note that if no widget/layout is specified it is assumed
|
|
|
that the View has a Frame Widget and uses a Form Layout.
|
|
|
Also this is used as the default widget for any
|
|
|
attributes/items that don't specify one-->
|
|
|
<DefaultColor>1., 1., 0.5, 1.</DefaultColor>
|
|
|
<InvalidColor>1, 0.5, 0.5, 1</InvalidColor>
|
|
|
<Views>
|
|
|
<View Title="Time" />
|
|
|
</Views>
|
|
|
</View>
|
|
|
|
|
|
<View Type="Instanced" Title="Time">
|
|
|
<Att Name="Time" Type="Time">
|
|
|
<Widget Type="Frame" Layout="Form">
|
|
|
<Item Path="StartTime" Widget="Frame" Layout="HBox"/>
|
|
|
<!-- The following would produce the same GUI as the element above -->
|
|
|
<Widget Type="Frame" Layout="HBox">
|
|
|
<Item Path="StartTime"/>
|
|
|
</Widget>
|
|
|
<Item Path="EndTime" Widget="Frame" Layout="HBox"/>
|
|
|
</Widget>
|
|
|
|
|
|
<Item Path="TimestepSize"/>
|
|
|
<Widget Name="Options" Type="CollGroupBox" Layout="Form" >
|
|
|
<Item Name="Time.*"/>
|
|
|
</Widget>
|
|
|
</Att>
|
|
|
</View>
|
|
|
</Views>
|
|
|
```
|
|
|
# Design Discussion
|
|
|
## Current Design
|
|
|
Consists of the following classes:
|
|
|
### QT View Related Classes
|
|
|
These include qtBaseView and derived classes qtGroupView, qtInstanstancedView and qtAttributeView. These classes generate the GUI based on the information stored in a SMTK View. These classes (along with the UI Manager) are responsible for performing “access” and “category” Filtering of items.
|
|
|
### qtAttribute
|
|
|
This class deals with the generation of QT WIdgets based on the items it contains. It has a reference to a qtBaseView so it can omit items that should not be displayed. This class is also the factory for generating qtItems.
|
|
|
### qtItem Related Classes
|
|
|
These include qtItem and derived classes qtGroupItem, qtInputsItems, qtFileItem, qtDirectoryItem, qtModelEnityItem, qtAttributeRefItem and qtMeshEnityItem. These classes hold onto the SMTK Attribute Item so it knows how to set and update values. It is also responsible for creating the widgets and labels.
|
|
|
### UI Manager
|
|
|
In addition to providing overall management of the UI generated based on a set of SMTK Views, the manager also provides some support for laying out items (in particular InputItems which are doubles, ints, and strings)
|
|
|
|
|
|
## Proposed Design
|
|
|
To provide an extensible UI generation system that provides better control over layout as well as the possibility of adding new types of widgets and layout strategies. The one major change in terms of file format (now version 3) will be the inclusion of Widget information as shown in the above XML.
|
|
|
The following are the proposed set of new classes and their role in the GUI construction
|
|
|
### QT Related View Classes
|
|
|
These classes will maintain their role in the system. Currently these classes are in the smtk::attribute namespace. In this new design they will be part of smtk::extensions (note since these are qt classes and have a qt in the name there is no need for qt namespace. Their main job is converting a View Description into a set of GUI elements. A view is a collection of smtk::extensions::qtWidgets and child Views. **Question:Should there be a custom type of View or Widget to represent the TopLevel aspects?** Right now the top level aspect (which includes category and access filtering) can be added to any View GUI but this does make things complicated.
|
|
|
#### Methods
|
|
|
* Constructor - takes in a qtViewInfo object (includes smtk::common::View, parent qtView, UIManager)
|
|
|
* applyFilter - apply a items filter object to the view and its children widgets (rebuilds the View). Would be used to deal with category and access filtering.
|
|
|
|
|
|
### smtk::extensions::qtWidget classes
|
|
|
These classes represent QWidgets that are defined by a View::Component object. They are not derived from QWidget but instead internally hold onto a QWidget. Main reason for this is to not to implement the QWidget interface in the class and delegating it to the internal widget. This class needs to be able to process the following elements:
|
|
|
* Widget - these would be children of this Widget
|
|
|
* Attribute - SMTK Attributes which are contained within this Widget
|
|
|
* Item - SMTK Attribute Item which is being placed within this Widget
|
|
|
|
|
|
Deleting this class will destroy the QWidget (if its not already deleted - therefore we would be using a QPointer and remove it from the parent layout).
|
|
|
Initial set of implemented classes would be:
|
|
|
* qtFrame
|
|
|
* qtCollaspibleGroupBox
|
|
|
* qtTabWidget
|
|
|
* qtScrollArea
|
|
|
|
|
|
#### Methods
|
|
|
* Constructor - takes in a qtWidgetInfo object (includes smtk::common::View::Component, parent qtView?, Layout?, UIManager)
|
|
|
* applyFilter - apply a items filter object to the view and its children widgets (rebuilds the View). Would be used to deal with category and access filtering.
|
|
|
* processAttribute(...)
|
|
|
* processItem(...)
|
|
|
* process(Widget(...)
|
|
|
|
|
|
### smtk::extensions::qtLayout classes
|
|
|
These classes provide layout management based on the information contained in a SMTK View::Component object. The main question here is whether this class directly builds the widgets for attribute::Item or does the owning Widget or do we have a set of classes do the construction. The answer to this also would help address the issue of how to extend things. For example how do we add new layouts and new widgets?
|
|
|
#### Methods
|
|
|
* Constructor - takes in a qtLayoutInfo object (includes smtk::common::View::Component, parent qtWidget, UIManager)
|
|
|
* addItem(...)? - if this class creates a widget for the item
|
|
|
* addWidget(...)
|
|
|
|
|
|
|
|
|
# Discussion Points
|
|
|
* View-based GUI Layouts - specify how the View itself could look like and the Attribute GUI could then refer to it as well as add its own widgets to it.
|
... | ... | |