<P>
While Ion does not not have a truly object-oriented design
<A NAME="tex2html1"
- HREF="#foot212"><SUP><SPAN CLASS="arabic">1</SPAN></SUP></A>,
+ HREF="#foot210"><SUP><SPAN CLASS="arabic">1</SPAN></SUP></A>,
things that appear on the computer screen are, however, quite
-naturally expressed as such ''objects''. Therefore Ion implements
+naturally expressed as such ``objects''. Therefore Ion implements
a rather primitive OO system for these screen objects and some
other things.
<P>
For simplicity we consider only the essential-for-basic-configuration
Ioncore, <SPAN CLASS="textit">mod_tiling</SPAN> and <SPAN CLASS="textit">mod_query</SPAN> classes.
-See Appendix <A HREF="#app:fullhierarchy"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]" SRC="crossref.png"></A> for the full class hierachy visible
+See Appendix <A HREF="#app:fullhierarchy"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]" SRC="crossref.png"></A> for the full class hierarchy visible
to Lua side.
<P>
<P>
-<DIV ALIGN="CENTER"><A NAME="fig:classhierarchy"></A><A NAME="318"></A>
+<DIV ALIGN="CENTER"><A NAME="fig:classhierarchy"></A><A NAME="317"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 1:</STRONG>
Partial Ioncore, <SPAN CLASS="textit">mod_tiling</SPAN> and <SPAN CLASS="textit">mod_query</SPAN>
<P>
<DL>
<DT><STRONG>Obj</STRONG></DT>
-<DD><A NAME="324"></A>
+<DD><A NAME="323"></A>
Is the base of Ion's object system.
<P>
</DD>
<DT><STRONG>WRegion</STRONG></DT>
-<DD><A NAME="325"></A>
+<DD><A NAME="324"></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 big 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''
+ 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</STRONG></DT>
-<DD><A NAME="326"></A> is a class for
+<DD><A NAME="325"></A> 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="327"></A> is the base class for all
+<DD><A NAME="326"></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="328"></A> is the class for
- root windows<A NAME="242"></A> of X screens<A NAME="243"></A>.
- Note that an ''X screen'' or root window is not necessarily a
- single physical screen<A NAME="244"></A> as a root window
- may be split over multiple screens when hacks such as
- Xinerama<A NAME="245"></A> are used. (Actually there can be only
- one root window when Xinerama is used.)
-
<P>
</DD>
<DT><STRONG>WMPlex</STRONG></DT>
-<DD>is a base class for all regions that''multiplex''
+<DD>is a 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. Classes that inhereit WMPlex
- include screens and frames.
+ only one can be displayed at a time.
<P>
</DD>
<DT><STRONG>WScreen</STRONG></DT>
-<DD><A NAME="329"></A> is the class for objects
- corresponding to physical screens. Screens may share a root
- window when the Xinerama extension is used as explained above.
+<DD><A NAME="327"></A> is an instance of WMPlex
+ for screens.
+
+<P>
+</DD>
+<DT><STRONG>WRootWin</STRONG></DT>
+<DD><A NAME="328"></A> is the class for
+ root windows<A NAME="244"></A> of X screens<A NAME="245"></A>.
+ It is an instance of WScreen.
+ Note that an ``X screen'' or root window is not necessarily a
+ single physical screen<A NAME="247"></A> as a root window
+ may be split over multiple screens when ugly hacks such as
+ Xinerama<A NAME="248"></A> are used. (Actually there can be only
+ one root window when Xinerama is used.)
<P>
</DD>
<DT><STRONG>WFrame</STRONG></DT>
-<DD><A NAME="330"></A> is the class for frames.
- While most Ion's objects have no graphical presentation, frames basically
- add to WMPlexes the decorations around client windows
- (borders, tabs).
+<DD><A NAME="329"></A> is the class for frames.
+ While most Ion's objects have no graphical presentation, frames
+ basically add to WMPlexes the decorations around client
+ windows (borders, tabs).
<P>
</DD>
<DT><STRONG>WGroup</STRONG></DT>
-<DD><A NAME="331"></A> is the base class for groups.
+<DD><A NAME="330"></A> is the base class for groups.
Particular types of groups are workspaces
- (WGroupWS<A NAME="332"></A>)
+ (WGroupWS<A NAME="331"></A>)
and groups of client windows
- (WGroupCW<A NAME="333"></A>).
+ (WGroupCW<A NAME="332"></A>).
</DD>
</DL>
<P>
<DL>
<DT><STRONG>WTiling</STRONG></DT>
-<DD><A NAME="335"></A> is the class for tilings
+<DD><A NAME="334"></A> is the class for tilings
of frames.
</DD>
<DT><STRONG>WSplit</STRONG></DT>
-<DD><A NAME="336"></A> (or, more specifically, classes
+<DD><A NAME="335"></A> (or, more specifically, classes
that inherit it) encode the WTiling tree structure.
</DD>
</DL>
<P>
<DL>
<DT><STRONG>WInput</STRONG></DT>
-<DD><A NAME="338"></A> is a virtual base class for the
+<DD><A NAME="337"></A> is a virtual base class for the
two classes below.
</DD>
<DT><STRONG>WEdln</STRONG></DT>
-<DD><A NAME="339"></A> is the class for the ''queries'',
+<DD><A NAME="338"></A> is the class for the ``queries'',
the text inputs that usually appear at bottoms of frames and sometimes
- screens. Queries are the functional equivalent of ''mini buffers'' in
+ screens. Queries are the functional equivalent of ``mini buffers'' in
many text editors.
</DD>
<DT><STRONG>WMessage</STRONG></DT>
-<DD><A NAME="340"></A> implements the boxes for
+<DD><A NAME="339"></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>
-There are also some other ''proxy'' classes that do not refer
+There are also some other ``proxy'' classes that do not refer
to objects on the screen. The only important one of these for
basic configuration is WMoveresMode that is used for
binding callbacks in the move and resize mode.
<SPAN CLASS="arabic">1</SPAN>.<SPAN CLASS="arabic">2</SPAN>.<SPAN CLASS="arabic">1</SPAN> Parent-child relations</A>
</H3>
Each object of type WRegion has a parent and possibly a manager
-associated to it. The parent<A NAME="281"></A> for an object is always a
+associated to it. The parent<A NAME="280"></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.
<P>
-<DIV ALIGN="CENTER"><A NAME="fig:parentship"></A><A NAME="292"></A>
+<DIV ALIGN="CENTER"><A NAME="fig:parentship"></A><A NAME="291"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 2:</STRONG>
Most common parent-child relations</CAPTION>
<P>
WRegions have very little control over their children as a parent.
-The manager<A NAME="296"></A> WRegion has much more control over its
+The manager<A NAME="295"></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
<P>
-<DIV ALIGN="CENTER"><A NAME="fig:managership"></A><A NAME="304"></A>
+<DIV ALIGN="CENTER"><A NAME="fig:managership"></A><A NAME="303"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 3:</STRONG>
Most common manager-managed relations</CAPTION>
<P>
<BR><HR><H4>Footnotes</H4>
<DL>
-<DT><A NAME="foot21
2">... design</A><A
+<DT><A NAME="foot21
0">... design</A><A
HREF="node2.html#tex2html1"><SUP><SPAN CLASS="arabic">1</SPAN></SUP></A></DT>
<DD>the author doesn't like such artificial designs
projects / ion3.git / blobdiff