<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!--Converted with LaTeX2HTML 2002-1 (1.69)
original version by: Nikos Drakos, CBLU, University of Leeds
* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>2. Preliminaries: Key concepts and relations</TITLE>
<META NAME="description" CONTENT="2. Preliminaries: Key concepts and relations">
<META NAME="keywords" CONTENT="ionconf">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
<LINK REL="STYLESHEET" HREF="ionconf.css">
<LINK REL="next" HREF="node4.html">
<LINK REL="previous" HREF="node2.html">
<LINK REL="up" HREF="ionconf.html">
<LINK REL="next" HREF="node4.html">
</HEAD>
<BODY >
<!--Navigation Panel-->
<A NAME="tex2html234"
HREF="node4.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
<A NAME="tex2html228"
HREF="ionconf.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A>
<A NAME="tex2html222"
HREF="node2.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A>
<A NAME="tex2html230"
HREF="node1.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>
<A NAME="tex2html232"
HREF="node10.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index.png"></A>
<BR>
<B> Next:</B> <A NAME="tex2html235"
HREF="node4.html">3. Basic configuration</A>
<B> Up:</B> <A NAME="tex2html229"
HREF="ionconf.html">Ion: Configuring and extending</A>
<B> Previous:</B> <A NAME="tex2html223"
HREF="node2.html">1. Introduction</A>
<B> <A NAME="tex2html231"
HREF="node1.html">Contents</A></B>
<B> <A NAME="tex2html233"
HREF="node10.html">Index</A></B>
<BR>
<BR>
<!--End of Navigation Panel-->
<!--Table of Child-Links-->
<A NAME="CHILD_LINKS"><STRONG>Subsections</STRONG></A>
<UL>
<LI><A NAME="tex2html236"
HREF="node3.html#SECTION00310000000000000000">2.1 Modules</A>
<LI><A NAME="tex2html237"
HREF="node3.html#SECTION00320000000000000000">2.2 Class and object hierarchies</A>
<UL>
<LI><A NAME="tex2html238"
HREF="node3.html#SECTION00321000000000000000">2.2.1 Class hierarchy</A>
<LI><A NAME="tex2html239"
HREF="node3.html#SECTION00322000000000000000">2.2.2 Object hierarchies: WRegion parents and managers</A>
<LI><A NAME="tex2html240"
HREF="node3.html#SECTION00323000000000000000">2.2.3 Summary</A>
</UL></UL>
<!--End of Table of Child-Links-->
<HR>
<H1><A NAME="SECTION00300000000000000000"></A>
<A NAME="chap:prelim"></A>
<BR>
2. Preliminaries: Key concepts and relations
</H1>
<P>
The purpose of this chapter to explain some of key concepts and
relations you need to understand before reading the following
chapters. These include modules explained in section <A HREF="#sec:modules">2.1</A>
and the Ion class and object hierarchies, section <A HREF="#sec:objects">2.2</A>.
<P>
<H2><A NAME="SECTION00310000000000000000"></A>
<A NAME="sec:modules"></A>
<BR>
2.1 Modules
</H2>
<P>
Ion has been designed so that the 'ion' executable only implements some
basic services on top of which very different kinds of window managers
could be build by loading the appropriate 'modules'. On modern system
these modules are simply dynamically loaded <I>.so</I> libraries. On
more primitive systems, or if you want to squeeze total size of the
executable and libraries, the modules can optionally be statically
linked to the main binary, but must nevertheless be loaded with the
<A HREF="node7.html#fn:load_module"><TT>load_module</TT></A> function.
<P>
If no modules are loaded, all client windows appear in full screen mode.
To get better window management support, one or more workspace modules
should be loaded. Currently the <I>ionws</I> and <I>floatws</I>
workspace modules are provided. The formed provides the tiled workspaces
familiar from older versions of Ion, while the latter provides the PWM
flavour of conventional workspaces with freely ''floating'' windows.
<P>
Workspace modules alone don't yet make the WM very usable. Better
input capabilities are achieved through the <I>query</I> and <I>menu</I>
modules. So-called drawing engines are also implemented as a modules,
but they are not discussed here; see chapter <A HREF="node5.html#chap:gr">4</A>.
<P>
The stock configuration for the 'ion' executable loads all the modules
mentioned above. The stock configuration for the 'pwm' executable (which
differs from the 'ion' executable in a few configuration details, such
as Xinerama usage) does not load the <I>ionws</I> module.
<P>
<P>
<H2><A NAME="SECTION00320000000000000000"></A>
<A NAME="sec:objects"></A>
<BR>
2.2 Class and object hierarchies
</H2>
<P>
While Ion does not not have a truly object-oriented design
<A NAME="tex2html3"
HREF="#foot256"><SUP>2.1</SUP></A>,
things that appear on the computer screen are, however, quite
naturally expressed as such ''objects''. Therefore Ion implements
a rather primitive OO system for these screen objects and some
other things.
<P>
It is essential for the module writer to learn this object
system, but also people who write their own binding configuration files
necessarily come into contact with the class and object hierarchies
- you need to know which binding setup routines apply where,
and what functions can be used as handlers in which bindings.
It is the purpose of this section to attempt to explain these
hierarchies. If you do not wish the read the full section, at least
read the summary at the end of it, so that you understand the very
basic relations.
<P>
<H3><A NAME="SECTION00321000000000000000">
2.2.1 Class hierarchy</A>
</H3>
<P>
One of the most important principles of object-oriented design methodology
is inheritance; roughly how classes (objects are instances of classes)
extend on others' features. Inheritance gives rise to class hierarchy.
In the case of single-inheritance this hierarchy can be expressed as a
tree where the class at the root is inherited by all others below it
and so on. Figure <A HREF="#fig:classhierarchy">2.1</A> lists out the Ion class
hierarchy and below we explain what features of Ion the classes
implement.
<P>
<DIV ALIGN="CENTER"><A NAME="fig:classhierarchy"></A><A NAME="262"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 2.1:</STRONG>
Ion class hierarchy. The string in parenthesis indicates
the module in which this class is implemented if not in Ioncore.</CAPTION>
<TR><TD><PRE>
WObj
|
|-->WRegion
| |
| |-->WClientWin
| |
| |-->WWindow
| | |
| | |-->WRootWin
| | |
| | |-->WMPlex
| | | |
| | | |-->WScreen
| | | |
| | | |-->WGenFrame
| | | |
| | | |-->WIonFrame (ionws module)
| | | |
| | | |-->WFloatFrame (floatws module)
| | |
| | |-->WInput (query module)
| | |
| | |-->WEdln (query module)
| | |
| | |-->WMessage (query module)
| |
| |-->WGenWS
| |
| |-->WIonWS (ionws module)
| |
| |-->WFloatWS (floatws module)
|
|-->WWsSplit (ionws)
</PRE></TD></TR>
</TABLE>
</DIV>
<P>
The core classes:
<P>
<DL>
<DT><STRONG>WObj</STRONG></DT>
<DD><A NAME="368"></A>
Is the base of Ion's object system.
<P>
</DD>
<DT><STRONG>WRegion</STRONG></DT>
<DD><A NAME="369"></A>
is the base class for everything corresponding to something on the
screen. Each object of type WRegion has a size and position
relative to the parent WRegion. While a great part of Ion
operates on these instead of more specialised classes, WRegion
is a ''virtual'' base class in that there are no objects of ''pure''
type WRegion; all concrete regions are objects of some class
that inherits WRegion.
<P>
</DD>
<DT><STRONG>WClientWin<A NAME="370"></A></STRONG></DT>
<DD>is a class for
client window objects - the objects that window managers are
supposed to manage.
<P>
</DD>
<DT><STRONG>WWindow</STRONG></DT>
<DD><A NAME="371"></A> is the base class for all
internal objects having an X window associated to them
(WClientWins also have X windows associated to them).
<P>
</DD>
<DT><STRONG>WRootWin</STRONG></DT>
<DD><A NAME="372"></A> is the class for
root windows<A NAME="282"></A> of X screens<A NAME="283"></A>.
Note that an ''X screen'' or root window is not necessarily a
single physical screen<A NAME="284"></A> as a root window
may be split over multiple screens when multi-head extensions
such as Xinerama<A NAME="285"></A> are used. (Actually there
can be only one WRootWin when Xinerama is used.)
<P>
</DD>
<DT><STRONG>WMPlex</STRONG></DT>
<DD>is again a virtual base class for all regions that
''multiplex'' other regions. This means that of the regions managed by
the multiplexer, only one can be displayed at a time. WMPlexes
include screens and the different types of frames.
<P>
</DD>
<DT><STRONG>WScreen</STRONG></DT>
<DD><A NAME="373"></A> is the class for objects
corresponding to physical screens. Screens may share a root
window when Xinerama multihead extensions are used as explained
above.
<P>
</DD>
<DT><STRONG>WGenFrame</STRONG></DT>
<DD><A NAME="374"></A> is another virtual class
implementing what is common to the concrete frame classes but not
all WMPlexes. While most Ion's objects have no graphical
presentation, frames are basically the decorations around client
windows (borders, tabs).
<P>
</DD>
<DT><STRONG>WGenWS</STRONG></DT>
<DD><A NAME="375"></A> is a light virtual base class
for different types of workspaces.
</DD>
</DL>
<P>
Classes implemented by the ionws module:
<P>
<DL>
<DT><STRONG>WIonWS</STRONG></DT>
<DD><A NAME="376"></A> is the class for the
usual tiled workspaces.
</DD>
<DT><STRONG>WIonFrame</STRONG></DT>
<DD><A NAME="377"></A> implements the
style of frames seen on WIonWSs.
</DD>
<DT><STRONG>WWsSplit</STRONG></DT>
<DD><A NAME="378"></A> is an object internal to
WIonWS implementation and stores the tree structure of the
workspaces.
</DD>
</DL>
<P>
Classes implemented by the floatws module:
<P>
<DL>
<DT><STRONG>WFloatWS</STRONG></DT>
<DD><A NAME="379"></A> is the class for the
conventional workspaces where frames and other objects are
allowed to ''float'' around.
</DD>
<DT><STRONG>WFloatFrame</STRONG></DT>
<DD><A NAME="380"></A> implements the
frames seen on WFloatWSs decorated in the PWM style.
</DD>
</DL>
<P>
Classes implemented by the query module:
<P>
<DL>
<DT><STRONG>WInput</STRONG></DT>
<DD><A NAME="381"></A> is a virtual base class for the
two classes below.
</DD>
<DT><STRONG>WEdln</STRONG></DT>
<DD><A NAME="382"></A> is the class for the ''queries'',
the text inputs that usually appear at bottoms of frames and sometimes
screens. Quiries are the functional equivalent of ''mini buffers'' in
many text editors.
</DD>
<DT><STRONG>WMessage</STRONG></DT>
<DD><A NAME="383"></A> implements the boxes for
warning and other messages that Ion may wish to display to the user.
These also usually appear at bottoms of frames.
</DD>
</DL>
<P>
<H3><A NAME="SECTION00322000000000000000">
2.2.2 Object hierarchies: WRegion parents and managers</A>
</H3>
<P>
Each object of type WRegion has a parent and possibly a manager
associated to it. The parent<A NAME="324"></A> for an object is always a
WWindow and for WRegion with an X window (WClientWin,
WWindow) the parent WWindow is given by the same relation of
the X windows. For other WRegions the relation is not as clear.
There is generally very few restrictions other than the above on the
parent--child relation but the most common is as described in
Figure <A HREF="#fig:parentship">2.2</A>.
<P>
<DIV ALIGN="CENTER"><A NAME="fig:parentship"></A><A NAME="335"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 2.2:</STRONG>
Most common parent-child relations</CAPTION>
<TR><TD><PRE>
WRootWins
|
|-->WScreens
|
|-->WIonWS:s and WFloatWS:s
|
|-->WClientWins in full screen mode
|
|-->WIonFrames and WFloatFrames
|
|-->WClientWins, including transients
|
|-->a possible WEdln or WMessage
</PRE></TD></TR>
</TABLE>
</DIV>
<P>
WRegions have very little control over their children as a parent.
The manager<A NAME="339"></A> WRegion has much more control over its
managed WRegions. Managers, for example, handle resize requests,
focusing and displaying of the managed regions. Indeed the manager--managed
relationship gives a better picture of the logical ordering of objects on
the screen. Again, there are generally few limits, but the most common
hierarchy is given in Figure <A HREF="#fig:managership">2.3</A>. Note that sometimes
the parent and manager are the same object and not all objects may have
a manager (e.g. the dock in the dock module at the time of writing this)
but all have a parent-a screen if not anything else.
<P>
<DIV ALIGN="CENTER"><A NAME="fig:managership"></A><A NAME="346"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 2.3:</STRONG>
Most common manager-managed relations</CAPTION>
<TR><TD><PRE>
WRootWins
|
|-->WScreens
|
|-->full screen WClientWins
| |
| |-->transient WClientWins (dialogs)
|
|-->WIonWSs
| |
| |-->WIonFrames
| |
| |-->WClientWins
| | |
| | |-->transient WClientWins (dialogs)
| |
| |-->a possible WEdln or WMessage
|
|-->WFloatWSs
|
|-->WFloatFrames
|
|-->WClientWins
|
|-->a possible WEdln or WMessage
</PRE></TD></TR>
</TABLE>
</DIV>
<P>
Note how the WClientWins managed by WFloatFrames don't have
transients managed by them. This is because WFloatWSs choose to handle
transients differently (transients are put in separate frames like normal
windows; in the future they should be stacked above the frame containing the
<TT>transient_for</TT> window).
<P>
<H3><A NAME="SECTION00323000000000000000">
2.2.3 Summary</A>
</H3>
<P>
In the standard setup, keeping queries, messages and menus out of
consideration:
<P>
<UL>
<LI>The top-level objects that matter are screens and they correspond
to physical screens. The class for screens is WScreen.
</LI>
<LI>Screens contain (multiplex) workspaces and full screen client
windows. Only one of them can be viewed at a time.
Workspace classes are WIonWS and WFloatWS
for the two different types of workspaces (and WGenWS).
</LI>
<LI>Frames are put on workspaces. Frames are the objects with
decorations such as tabs and borders.
Different frame classes are WIonFrame and WFloatFrame
for the two types of frames. The common base class, the features and
bindings of which both of these inherit is WGenFrame.
<P>
Workspace of type WIonWS tile WIonFrames while
workspaces of type WFloatWS contain WFloatFrames
on a more traditional freely-floating fashion.
<P>
</LI>
<LI>Frames contain (multiplex) client windows, to each of which
corresponds a tab in the frame's decoration. Only one client
window (or other object) can be shown at a time in each frame.
The class for client windows is WClientWin.
</LI>
</UL>
<P>
<P>
<BR><HR><H4>Footnotes</H4>
<DL>
<DT><A NAME="foot256">... design</A><A
HREF="node3.html#tex2html3"><SUP>2.1</SUP></A></DT>
<DD>the author doesn't like such artificial designs
</DD>
</DL><HR>
<!--Navigation Panel-->
<A NAME="tex2html234"
HREF="node4.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
<A NAME="tex2html228"
HREF="ionconf.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A>
<A NAME="tex2html222"
HREF="node2.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A>
<A NAME="tex2html230"
HREF="node1.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>
<A NAME="tex2html232"
HREF="node10.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index.png"></A>
<BR>
<B> Next:</B> <A NAME="tex2html235"
HREF="node4.html">3. Basic configuration</A>
<B> Up:</B> <A NAME="tex2html229"
HREF="ionconf.html">Ion: Configuring and extending</A>
<B> Previous:</B> <A NAME="tex2html223"
HREF="node2.html">1. Introduction</A>
<B> <A NAME="tex2html231"
HREF="node1.html">Contents</A></B>
<B> <A NAME="tex2html233"
HREF="node10.html">Index</A></B>
<!--End of Navigation Panel-->
</BODY>
</HTML>
