|
|
SMTK provides a mechanism to generate QT-based GUIs given a SMTK View description. There are unfortunately several limitations in terms of how an attribute and its items are mapped into their GUI counterparts. This page is focused on discussing how this can be improved.
|
|
|
|
|
|
# Current Functionality
|
|
|
|
|
|
Below is an example of a complete View description in SMTK V2:
|
|
|
|
|
|
```xml
|
... | ... | @@ -68,13 +69,14 @@ Below is an example of a complete View description in SMTK V2: |
|
|
</View>
|
|
|
</Views>
|
|
|
```
|
|
|
As you can see the Att Elements nor the View Elements do not have any formatting/layout information, nor do they have any layout info.
|
|
|
As you can see neither the Att Elements nor the View Elements have any formatting/layout information.
|
|
|
|
|
|
# Adding Formatting Information into View Specification
|
|
|
|
|
|
The main use case I'm focussing on is one that lets the designer specify the layout of an attribute's items within a single widget and not the more general case of being able to generally mix the items of one attribute those of another - this would primarily be used in an Instanced View.
|
|
|
The main use case I'm focusing on is one that lets the designer specify the layout of an attribute's items within a single widget and not the more general case of being able to generally mix the items of one attribute with those of another - this would primarily be used in an Instanced View.
|
|
|
|
|
|
## Adding Widget Elements
|
|
|
|
|
|
##Adding Widget Elements
|
|
|
These Elements would represent a GUI tree of widgets which could then be referenced by attributes and item elements. Here is what one could look like:
|
|
|
|
|
|
```xml
|
... | ... | @@ -94,9 +96,10 @@ These Elements would represent a GUI tree of widgets which could then be referen |
|
|
</InstancedAttributes>
|
|
|
</View>
|
|
|
```
|
|
|
|
|
|
Couple of things to note:
|
|
|
* If the widget attribute is omitted then the item is placed in the layout of the View itself
|
|
|
* Setting an Item Name to * means all remaining items
|
|
|
* Setting an Item Name to `*` means all remaining items
|
|
|
* The designer can choose to omit items from being displayed
|
|
|
* The NoLabels attribute means that the item should not draw any of its labels
|
|
|
|
... | ... | @@ -107,6 +110,7 @@ In terms of Widget Types, an initial list could be: |
|
|
* Collapsible Group Box
|
|
|
|
|
|
# Updated Proposed Version
|
|
|
|
|
|
Based on feedback from several developers the following is the current proposed View Format:
|
|
|
|
|
|
```xml
|
... | ... | @@ -142,41 +146,61 @@ Based on feedback from several developers the following is the current proposed |
|
|
</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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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. **Answer numero 1: Non.** To keep things simple, it would be preferable to avoid special cases. Also, it may be that category/access filtering becomes more meaningful to subviews – say by adding a search text entry field. It's unclear what the complications are with allowing any view to behave like a top-level view... is it just a matter of removing the filtering UI elements? If so, perhaps it would be better for views to turn these off by default and force XML authors to mark the toplevel view specially.
|
|
|
|
|
|
#### 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
|
|
|
* qtCollapsibleGroupBox
|
|
|
* 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(...)
|
... | ... | @@ -184,14 +208,17 @@ Initial set of implemented classes would be: |
|
|
* 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.
|
|
|
* How do we control Tab-Ordering for navigating through the widgets?
|
|
|
* How do we control Tab-Ordering for navigating through the widgets? A starting point might by looking at Qt's own XML format for tabs.
|
|
|
* Labels for Attributes and Items could now be overridden in a View. |
|
|
\ No newline at end of file |