... | ... | @@ -182,6 +182,8 @@ These classes will maintain their role in the system. Currently these classes a |
|
|
|
|
|
* 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.
|
|
|
* buildUI(...) - build the UI representation of the View
|
|
|
* destroyUI(...) - delete the UI representation of the View
|
|
|
|
|
|
### smtk::extensions::qtWidget classes
|
|
|
|
... | ... | @@ -206,6 +208,8 @@ Initial set of implemented classes would be: |
|
|
* processAttribute(...)
|
|
|
* processItem(...)
|
|
|
* process(Widget(...)
|
|
|
* buildUI(...) - build the UI representation of the View
|
|
|
* destroyUI(...) - delete the UI representation of the View
|
|
|
|
|
|
### smtk::extensions::qtLayout classes
|
|
|
|
... | ... | @@ -219,7 +223,15 @@ These classes provide layout management based on the information contained in a |
|
|
|
|
|
# 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? 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.
|
|
|
* Should the View XML have an outer "Att" tag? This seems like it could be a problem when we do eventually want to intermix items from multiple attributes in one view. Since we are using XPath-like references to items anyway, why not allow/require the attribute name to be part of it? Placeholder names for user-created attributes could be specified as part of the XML. |
|
|
\ No newline at end of file |
|
|
## 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.
|
|
|
## Controlling Tab Order?
|
|
|
A starting point might by looking at Qt's own XML format for tabs.
|
|
|
## Labels Support in Attribute and Items components
|
|
|
Labels for Attributes and Items could now be overridden in a View.
|
|
|
## Role of Attribute elements (i.e. Att Components)
|
|
|
Should the View XML have an outer "Att" tag? This seems like it could be a problem when we do eventually want to intermix items from multiple attributes in one view. Since we are using XPath-like references to items anyway, why not allow/require the attribute name to be part of it?
|
|
|
**Bob** The use of the Att element would mean that all ItemPaths are relative to the Attribute referred to in the Att element. Or in the case of Attribute Definition Elements - the Item Definition Paths would be relative to the type of AttDef in the parent element.
|
|
|
|
|
|
|
|
|
Placeholder names for user-created attributes could be specified as part of the XML. |
|
|
\ No newline at end of file |