This section will provide you with a general explanation of the windows composed in a Skeleton-based application as well as an understanding of where the application places them.
An application based upon the Skeleton Framework must supply different windows that represent the different views and editors of the graphical user interface. In every case, an application has a top-level window that contains and manages any number of child windows. A child window may, for instance, be a menubar, toolbar, repository view, layout toolbox, navigator view or an editor to model or manipulate a graph.
Within the Tensegrity Skeleton Framework, each window is defined by a unique public interface. This interface defines the window type as well as the methods needed to manage it.
The top-level window is an implementation of the interface ApplicationFrame
and consists of components and containers. Components implement the BaseComponent
interface and represent things like menubars, toolbars and statusbars. Containers, on the other hand,
implement the Container interface and represent views and editors like the layout
toolbox, the repository view and the navigator view.
The ApplicationFrame is divided into four distinct locations:
Menubar Component. The location of the menubar is directly beneath the title of the top-level window.
Toolbar Component. The location of the toolbar is usually just below the menubar.
Statusbar Component. The location of the statusbar is at the bottom of the top-level window.
Containers. Between the toolbar and statusbar are located all concrete Containers .
All child windows (Components and Containers) are requested by the
ApplicationFrame calling different methods on itself. These methods
must be overridden whenever a concrete ApplicationFrame class is
implemented to ensure that the correct concrete child window types are returned.
Concretion in the context of the Tensegrity Skeleton Framework is done
in two steps. Firstly, you specify the windowing toolkit implementation of your choice. In this
example, it is the Swing API. Secondly, you must derive from this implementation base class.
Our ApplicationFrame implementation class therefore belongs to this
class hierarchy:
ApplicationFrame
==> SwingApplicationFrame
==> ExampleApplicationFrame
The menubar is represented by a concrete implementation of the MenuBar
interface. It is requested from an ApplicationFrame instance through its
method getMenuBar().
Each item of a menu embeds a Command object. Command
classes are explained in a later section in more detail.
A Skeleton-based application creates a set of default menus such as File,
Edit, View, Tools, Window and Help. Each of these default menus references a default command
object. During application startup, default menus are added to the
ApplicationFrame instance automatically.
In order to modify the default menus or to add your own menu to the menubar, you have to
override the corresponding LauncherTask. In the case of a custom
menu, you will have to write a command class first, then create a
LauncherTask to create and insert the menu item.
LauncherTask classes are explained in more detail in a later section.
A toolbar is represented by a concrete implementation of the ToolBar
interface. It is requested from an ApplicationFrame instance through its
method getToolbars(). As the method name implies, there can be more than
one ToolBar instance.
Each button in a toolbar embeds a Command object. Command
classes are explained in a later section in more detail.
A Skeleton-based application creates a default toolbar. If you wish to hide
it you should return null when overriding the method
getToolBars() in your ApplicationFrame derived class.
It is also possible to modify the default toolbar. To do so, you will have to write a command class
first, then create a LauncherTask to create and insert the toolbar button.
LauncherTask classes are explained in more detail in a later section.
The statusbar is represented by a concrete implementation of the StatusBar
interface. It is requested from an ApplicationFrame instance through its
method getStatusBar().
The statusbar displays a description the currently selected and executed command as well as other
useful information. It is automatically linked to the commands embedded in the menubar and toolbar.
A statusbar is provided by default. The statusbar may be hidden or modified in the same way as the
menubar and toolbar by returning null in the
getStatusBar() method.
A Container is an element of the graphical user interface that cannot
be handled in the same way as a Component (menubar, toolbar, statusbar).
Containers represent complex views and editors that depend on the document types handled by the
application.
In the Tensegrity Graph API, a Container is a word used in a graphical context and
is not the same thing as the word “Container” used in a other programming
contexts, such as in pure AWT or in a J2EE or another IoC
[2]
application. Here we are referring to the main application window's many embedded graphical
panels. Each panel is capable of holding various tools or complex elements and is therefore
called a Container, thereby assisting users with the selection of
repository elements, navigation, viewing and setting attribute values and more.
Examples of containers needed for a graph application include a repository view, from which users may drag elements and drop them into a document, a navigator, which provides a miniaturized overview of the entire graph, and a layout toolbox, in which a user may select different layout types, change their context attributes and apply them to a graph document.
The Tensegrity Skeleton Framework defines several standard containers that are needed or helpful in a graph application. The following list gives an overview of these standard containers (some of these are used in this tutorial's application, others not):
A RepositoryContainer, which provides the elements
a graph may consist of.
A LayoutToolsContainer, which provides users with
several layout algorithms.
A NavigatorContainer, which provides users with
an overview of the entire graph, allowing them to easily navigate through the
graph or choose an appropriate zoom factor.
An OutlinerContainer, which provides users with an outline
of the currently active document.
An AttributeTreeContainer, which provides users with the
attributes of the currently selected elements, allowing them to be modified.
Finally, it is possible to create a custom Container by implementing
this interface and introducing another concrete container type needed for your specialized
application. This is not explained in this tutorial, however. Please refer to the Framework Manual
for detailed information on this subject.
[2] Inversion of Control (IoC) is an architectural pattern in which parent containers manage the lifecycle and dependencies of child components.
© 2004, 2005 Tensegrity Software GmbH