Attributes of {low} importance are only placed in a details group (see below).
Attributes of {normal} importance are shown in the same window, if possible.
Attributes of {high} importance:
If they are boolean and false, they largely decrease the importance of the containing object .
They are the (default) primary sort criteria by default.
Displayed as attribute, while the object is only represented by the {name}. If it is a to-1-relationship, a drop-down-list is used together with a "Details..."-Button, which opens the details group of the selected object as dialog. The set of objects can't be changed here (i.e. no new objects can be created and no object can be deleted).
If it is a to-many-relationship, the drop-down-list is substituted with a multi-select-list.
[Mainly the following rules define the structure of the UI.]
Relations of {low} importance are only shown
in the details group.
using a context menu entry (one for each relationship), which creates a new window showing the target objects and their attributes.
Target objects of to-1-relationships are merged into the containing object.
There are 3 possible, alternative strategies:
Look&feel is more like that of traditional applications.
This strategy depends on the capability of the tree to show several columns, each of which can display one attribute of the object. Such a tree looks like Mozilla Mailnews' thread pane in threaded mode or GNOME Control Center|Multimedia|Sound|Sound Events.
Try to put every object representation in as less trees as possible (see Constraints/Tree).
Turn all trees, that end up having only one level (i.e. all nodes are root nodes) into lists.
This strategy creates a 2-pane window, the left one being a single-column tree and the right one showing both the content group and the details group for the in the tree selected object, organized as notebook.
Look&feel is that of like Microsoft Windows Explorer in hierarchical mode.
Like Details group, but for attributes of {normal} or higher importance.
Shows all objects (of {normal} or higher importance) with their {name}s.
The contains objects of various types, not even all childs of the same node have to be of the same type. Types are visualized by icons.
A click on an object opens the corresponding group on the right.
If type A has a containing, editable to-many-relationship to type B, a D&D of an object b of type B on an object a of type A moves or copies b to a, while the move has a higher importance.
If the result is an UI object, it is always shown as popup. (The app (model) may also add it to other containers.)
Actions are added to the context menu.
enum or boolean type parameters just create more menu entries, either as submenu or longer text description.
Parameters of other types create dialogs.
If the only parameter has a type of another UI object, the latter can be dragged on the object to trigger the action.
All attributes are shown in the details group.
Attributes of build-in types are implemented using the following mapping table:
Table 2-1. Mapping of built-in types
| OOUI type | Tasket type |
|---|---|
| enum | Choice |
| boolean, integer, float, string, color, time, file | Corresponding basic or standard data type |