]> git.decadent.org.uk Git - ion3-doc.git/blobdiff - ionnotes/node2.html
[svn-upgrade] Integrating new upstream version, ion3-doc (20080411)
[ion3-doc.git] / ionnotes / node2.html
index 104875c2654ebb6b8c981f21444eb3c06c9187db..cdff64e32a787664283a108f30f3b0321d518e39 100644 (file)
@@ -87,7 +87,7 @@ original version by:  Nikos Drakos, CBLU, University of Leeds
 <P>
 While Ion does not not have a truly object-oriented design
 <A NAME="tex2html1"
-  HREF="#foot215"><SUP><SPAN CLASS="arabic">1</SPAN></SUP></A>,
+  HREF="#foot216"><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
 a rather primitive OO system for these screen objects and some
@@ -128,7 +128,7 @@ implement.
 
 <P>
 
-<DIV ALIGN="CENTER"><A NAME="fig:classhierarchy"></A><A NAME="322"></A>
+<DIV ALIGN="CENTER"><A NAME="fig:classhierarchy"></A><A NAME="323"></A>
 <TABLE>
 <CAPTION ALIGN="BOTTOM"><STRONG>Figure 1:</STRONG>
 Partial Ioncore, <SPAN  CLASS="textit">mod_tiling</SPAN> and <SPAN  CLASS="textit">mod_query</SPAN> 
@@ -160,13 +160,13 @@ The core classes:
 <P>
 <DL>
 <DT><STRONG>Obj</STRONG></DT>
-<DD><A NAME="332"></A>
+<DD><A NAME="329"></A>
     Is the base of Ion's object system.
 
 <P>
 </DD>
 <DT><STRONG>WRegion</STRONG></DT>
-<DD><A NAME="333"></A>
+<DD><A NAME="330"></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 
@@ -178,14 +178,14 @@ The core classes:
 <P>
 </DD>
 <DT><STRONG>WClientWin</STRONG></DT>
-<DD><A NAME="334"></A> is a class for
+<DD><A NAME="331"></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="335"></A> is the base class for all
+<DD><A NAME="332"></A> is the base class for all
     internal objects having an X window associated to them
     (WClientWins also have X windows associated to them).
 
@@ -199,25 +199,25 @@ The core classes:
 <P>
 </DD>
 <DT><STRONG>WScreen</STRONG></DT>
-<DD><A NAME="336"></A> is an instance of WMPlex
+<DD><A NAME="333"></A> is an instance of WMPlex
     for screens.
 
 <P>
 </DD>
 <DT><STRONG>WRootWin</STRONG></DT>
-<DD><A NAME="337"></A> is the class for
-    root windows<A NAME="249"></A> of X screens<A NAME="250"></A>.
+<DD><A NAME="334"></A> is the class for
+    root windows<A NAME="250"></A> of X screens<A NAME="251"></A>.
     It is an instance of WScreen.
     Note that an ``X screen'' or root window is not necessarily a
-    single physical screen<A NAME="252"></A> as a root window
+    single physical screen<A NAME="253"></A> as a root window
     may be split over multiple screens when ugly hacks such as 
-    Xinerama<A NAME="253"></A> are used. (Actually there can be only 
+    Xinerama<A NAME="254"></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="338"></A> is the class for frames.
+<DD><A NAME="335"></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).
@@ -225,11 +225,11 @@ The core classes:
 <P>
 </DD>
 <DT><STRONG>WGroup</STRONG></DT>
-<DD><A NAME="339"></A> is the base class for groups.
+<DD><A NAME="336"></A> is the base class for groups.
     Particular types of groups are workspaces 
-    (WGroupWS<A NAME="340"></A>)
+    (WGroupWS<A NAME="337"></A>)
     and groups of client windows
-    (WGroupCW<A NAME="341"></A>).
+    (WGroupCW<A NAME="338"></A>).
 </DD>
 </DL>
 
@@ -239,12 +239,12 @@ Classes implemented by the <SPAN  CLASS="textit">mod_tiling</SPAN> module:
 <P>
 <DL>
 <DT><STRONG>WTiling</STRONG></DT>
-<DD><A NAME="344"></A> is the class for tilings
+<DD><A NAME="340"></A> is the class for tilings
     of frames.
   
 </DD>
 <DT><STRONG>WSplit</STRONG></DT>
-<DD><A NAME="345"></A> (or, more specifically, classes
+<DD><A NAME="341"></A> (or, more specifically, classes
     that inherit it) encode the WTiling tree structure.
 </DD>
 </DL>
@@ -255,19 +255,19 @@ Classes implemented by the <SPAN  CLASS="textit">mod_query</SPAN> module:
 <P>
 <DL>
 <DT><STRONG>WInput</STRONG></DT>
-<DD><A NAME="348"></A> is a virtual base class for the
+<DD><A NAME="343"></A> is a virtual base class for the
     two classes below.
   
 </DD>
 <DT><STRONG>WEdln</STRONG></DT>
-<DD><A NAME="349"></A> is the class for the ``queries'',
+<DD><A NAME="344"></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
     many text editors.
   
 </DD>
 <DT><STRONG>WMessage</STRONG></DT>
-<DD><A NAME="350"></A> implements the boxes for 
+<DD><A NAME="345"></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>
@@ -291,7 +291,7 @@ 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="285"></A> for an object is always a 
+associated to it. The parent<A NAME="286"></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.
@@ -301,7 +301,7 @@ Figure <A HREF="#fig:parentship">2</A>.
 
 <P>
 
-<DIV ALIGN="CENTER"><A NAME="fig:parentship"></A><A NAME="296"></A>
+<DIV ALIGN="CENTER"><A NAME="fig:parentship"></A><A NAME="297"></A>
 <TABLE>
 <CAPTION ALIGN="BOTTOM"><STRONG>Figure 2:</STRONG>
 Most common parent-child relations</CAPTION>
@@ -321,14 +321,15 @@ Most common parent-child relations</CAPTION>
 
 <P>
 WRegions have very little control over their children as a parent.
-The manager<A NAME="300"></A> WRegion has much more control over its
+The manager<A NAME="301"></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">3</A>. Note that sometimes
 the parent and manager are the same object and not all regions may have
-a manager, but all have a parent-a screen if not anything else.
+a manager, but all non-screen regions have a parent--a screen if not 
+anything else.
 
 <P>
 
@@ -338,7 +339,7 @@ a manager, but all have a parent-a screen if not anything else.
 
 <P>
 
-<DIV ALIGN="CENTER"><A NAME="fig:managership"></A><A NAME="308"></A>
+<DIV ALIGN="CENTER"><A NAME="fig:managership"></A><A NAME="309"></A>
 <TABLE>
 <CAPTION ALIGN="BOTTOM"><STRONG>Figure 3:</STRONG>
 Most common manager-managed relations</CAPTION>
@@ -401,7 +402,7 @@ consideration:
 <P>
 <BR><HR><H4>Footnotes</H4>
 <DL>
-<DT><A NAME="foot215">... design</A><A
+<DT><A NAME="foot216">... 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