Class tree is a subclass of class device
which displays its
graphical objects
formatted as a hierarchy. Class tree fits well in PCE's
target domain: graphical interfaces for structured representations
(models).
The nodes of a PCE tree may be arbitrary graphical objects (yes, even trees, editors, etc.). Trees allow for multiple inheritance, but the automatically generated layout is often not optimal when multiple inheritance is used intensively. The automatically generated layouts for hierarchies are top-to-bottom, left-to-right (default) or‘indented list’.
Class tree itself is
responsible for displaying and formatting the nodes of the hierarchy.
The hierarchy is defined by node objects. A node
object refers to a graphical (using node<->image),
its parent node(s) and its son nodes.
Event-handling for trees may be done in two ways. The first is to
define event-handling for each of the individual graphicals representing
the nodes. The second is to associate recognisers with the tree
object itself. Class tree defines various different
recognisers, activation of which depends on the status of the node. See tree->event.
Sometimes, it is desirable to allow the user to move the nodes of a
tree by hand. With tree<-auto_layout: @on
this is not possible as the tree will immediately move the node back to
the original position.
See also tree->compute
and tree->layout.
->eventtop-to-bottom.
<-link
are used to determine the thickness, texture and colour of the lines.
Each node will, if it has sons, draw a line from (x + tree<-level_gap/2,
bottom side) down to halfway the last son. If to node is not the root,
it will draw a line from halfway its height towards the line from its
parent. See also node<->collapsed.
Note: the default tree is displayed left-to-right rather than top-to-bottom as the nodes are often much wider than high. Using left-to-right layout allows for displaying much larger hierarchies.
When a large number of items is to be displayed as an indented list,
also consider class list_browser.
The indentation may be realised using
list_browser->tab_stops.
->zoom
and tree->unzoom.
->eventsend(Tree?link, arrows, first).
will attach an arrow pointing to the root to every relation created after this call has been made.
<-son_handle
and tree<-parent_handle.
->eventThis handle is automatically updated by tree->direction..
<-display_root.
Class tree delegates
messages not understood to its tree<-root
node when present.
If the argument is *nil, all nodes are removed from the tree. If the
argument is a new root object the behaviour depends on the relink
argument. With relink = @off
(default), the tree is first cleared using tree->root: @nil,
after which the new root is attached. With relink = @on
the old root is added as the only node->son
of the new root.
See also tree->zoom
and tree->unzoom.
->event<-parent_handle,
but is the connection-point for the connection towards son-nodes.
<->collapsed.
See tree->event
for the interpretation.
->request_compute. tree->compute
recomputes the layout of the tree by invoking tree->layout.-parent_handle->event
allows for centralised event-processing for all nodes displayed on the
tree. It performs the following steps.
->event.
When successful, succeed.
->event
on the node below the pointer.
<-root
of the tree, iterating over all nodes of the tree. See also node->for_all, node->for_some
and
tree<-contains.
->root
before any other nodes may be attached.
Note that class node
defines a convert method for graphicals that creates a node with the
specified graphical as node<-image.
->compute
and sends the following three messages to tree<-display_root:
node ->compute_levelUpdate the node <-level slotsnode ->compute_sizeCompute the sizes of all nodes node ->compute_layoutPlace the nodes
.e.
are leaves). See tree->event
for the interpretation.
-neighbour_gap-neighbour_gap->event
for the interpretation.
->initialise<-display_root
node. See‘tree
tree->event’for
the interpretation.
send(Tree, zoom, Tree?root).
To unzoom only one level, use
send(Tree, zoom, Tree?display_root?parents?head).
Note that this method is ambiguous when the display_root has multiple parents.
<-display_root.
Its device functionality would be to return the chain of graphicals, holding only the graphicals for the displayed nodes and connections.
The contains-hierarchy for trees is defined as follows:
tree | node | | image
Image (being a graphical) may contain any number of sub-visuals.