In this section we list and describe several concepts often used in this manual without a further reference.
Files is a collections of trees (possibly acompanied with some meta data common to all trees). Although the in-memory representation of a file has always the same form, its “physical representation” (called format) may vary. The part of TrEd program responsible for reading and writing files in a specific format is called a I/O _backend. Depending on a format, files may differ in some features.
A tree in this context is a rooted oriented cycle-free graph of nodes.
In other words: it is a finite ordered set of objects called nodes (sometimes, but
not in this manual, also called verteces),
each of the nodes but one is connected to another node
called its parent-node. This connection
is called an edge. Such a structure is then called a tree if edges
never form a cycle, i.e.
by following an edge-path (e.g. a sequence of adjacent edges
leading from a node to its parent-node) we
never return to the node where we
started. There is exactly one node without a parent-node,
called the root of the tree.
Every edge-path in the tree leads to this node.
A is a parent-node of
B is a child-node
A. Nodes having the same
node as their parent-node are called siblings.
In TrEd's internal
representation of a tree, there are the following additional
links between nodes:
a link from a parent-node to one of its child-nodes (usually but not necessarily this is the first of its child-nodes in the linear ordering of the tree). This child-node is called the first-son of the parent-node.
First son is linked with its next sibling (if any), called its right-sibling node (or lbrother). This sibling is again connected to another sibling, etc, so that all siblings are connected and this connection contains no cycle. Hence child-nodes of each node form a (possibly empty) chain originating on the first-son and connecting all its siblings one after another. The last sibling in the chain is called the last-sibling or last-son.
For easier tree traversal, nodes in
also contain link representing a reversed version of the
previous “right-sibling” relation,
called left-sibling (or lbrother).
So, if a node
A is the
B is the
We have already describe a node as an object occuring in a tree and possibly connected to other nodes in the tree. Apart from that, every node may be associated with some data represented in form of an attribute-value structure (AVS or feature-structure if you like). Each members of this structure (also called an attribute) has a name and value. Each name may occure in AVS only once. The names of node's attributes and types of their values are file-specific (or in some cases I/O-backend specific). Generally, a value of an attribute may be of one of the following types (it must be noted that not all of the types are supported by the I/O backends equally):
enumerated type (a string value from a pre-defined list)
“flat” list of values of one of the above types,
i.e. a string of
This type is used e.g. by FS-backend.
constant (usually not very useful, but sometimes handy)
attribute-value stucture (implemented as a Perl hash reference, fully supported by PML-backend and partially emulated by FS-backend)
ordered list of values of any type except list
(implemented as a Perl array reference of the
Treex::PML::List class). Currently
only supported by PML-backend.
unordered list of values of any type except list (implemented and supported likewise).
alternative of values of any type except alternative
(implemented as a Perl array reference of the
Alternative is very similar to unordered list but as long
as it has only one single value,
it is represented by that value (rather
Treex::PML::Alt array reference containing that value).
Alternatives are currently supported by PML-backend.
The active node plays a similar role to that of a cursor in a text editor. Each view remembers its active node. In general, if we refer to the active or current node, we usually mean the active node of the active view. In the default setup, the active node is by default visually differentiated from other nodes by its red color (other nodes are displayed as yellow or black). However, it must be noted that a stylesheet can (and often does) change the coloring of the tree, including definin its own way to distinguish the active node.
Files in TrEd are further organized into collections called file lists. A file list is basically a list of filenames of files belonging to the collection.
A view is the part of TrEd window where
a tree is displayed. TrEd allows for
multiple views (created by splitting a view in half either along
the horizontal or vertical axis). Always, one of the views is
focused. This view is called the active view
(also the current view). All commands related to a file, tree and
node usually only apply to the active view (or more specifically,
to the objects it displays). The active view is visually
distinguishable from the other views by its thick black border.
Optionally, inactive views may also be stippled (see
StippleInactiveWindows). Views can display trees from one file but also from several
unrelated files. It is also possible to display a single tree in
several views simultaneously. Each view is associated with a
file list and a in-memory representation of a single
file from that file list (in case of the active
view called the current file list
and the current file).
This term refers to the text field that appears above all tree views in the main window of TrEd, just below toolbars. Its content is controlled by stylesheets and hooks. It is typically used to display textual representation of the tree in the current view, e.g. a sentence.
Status line is a text field that appears at the bottom of the main window of TrEd. It is content is controlled by hooks and is typically used to display additional information about the active node in the current view computed using by macros, etc.
TrEd by default offers only a small set of fundamental and generic tree-editing commands. Commands specific to certain purpose or data are typically implemented as user-defined macros. A macro is a small program (more specifically a Perl subroutine), typically associated with a keyboard shortcut or a menu item. See Section 15, “User Macros” for details.
Hooks are similar to macros but
they are called indirectly by TrEd
rather directly by the user, although they also
in a way response to a particular
event or action performed by the user. For example, every time
the user performs an action resulting in
a file being opened, TrEd
tries to locate and call a user-defined function
in the current annotation mode (described below).
See Section 15.9, “Hooks: automatically executed macros” for details.
Macros serving similar purpose and often related to
some specific data may be organized to sets
called annotation mode.
Each view is associated with a annotation mode (called the
current mode) and
the user may easilly switch from one mode to another.
If the user presses a keyboard shortcut,
TrEd tries to find
a binding for that shortcut in the current
annotation mode. If it fails, tries the same
with a default annotation mode called
Similar lookup applies when the user performs an
action which requires a hook
to be called.
See Section 15.10, “Using different sets of macros in different situations” for details.
The concept of minor modes is borrowed from GNU Emacs editor. Minor modes use hooks to provide additional functionality that is independent of the current annotation mode. Different minor modes can be used for different views. Currently TrEd ships with the following minor modes:
shows in the text view above the tree the information from a configurable number of preceding and following trees,
shows the active tree and a configurable number of neighboring trees on the left and right.
allows the user to manually adjust position of nodes in the view by dragging the nodes and pressing Shift or Control before drop to move the current node or the whole subtree to the position of the drop.
is a helper minor mode used by tree query macros to colour nodes that match the query.
A stylesheet is a set of rules (called
patterns) modifying the default appearance
of trees in a view. Each view initially uses a stylesheet provided
by the data file (which may be empty), but the user may instruct
the view to use another stylesheet. The same tree may be viewed
simultaneously in different views with completely different
stylesheets. If a very
complex visual presentation is required, stylesheet rules may be accompanied by
some further presentational code defined in a
For more information see Section 10, “Customizing Tree Appearance: Stylesheets”.
An extension package is a special type of a ZIP file recognized by TrEd, which provides some additional functionality to TrEd. It can be installed directly from TrEd using the Extension Manager by the individual users and usually contains macros (annotation modes), resource files, file lists of sample data, configurations of I/O backends, stylesheets etc. related to some specific annotation project. The format of an extension package is described in Section Section 17, “Extension Packages”.
I/O backend is a module of TrEd responsible for reading and writing files in some particular data format. Thus, adding support for a new data format only requires writing a corresponding I/O backend. Different data formats not only represent the data (trees, nodes, meta data) differently, but often differ in the ability to interchange data with other I/O backends because of the nature of the data. For example, while some I/O backends are rather generic, other are tightly bound to the actual content of the data (hence loading a file using one I/O backend and saving it in another may not work as expected in all cases). Nonetheless, most of the I/O backends used in TrEd are able to read the data and save them back without any loss of information. Detailed discussion of I/O backends can be found in Section 16, “I/O backends”.