]> git.decadent.org.uk Git - ion3-doc.git/blobdiff - ionnotes/node2.html
Merge commit '20080207' into HEAD
[ion3-doc.git] / ionnotes / node2.html
index db367a5e33c35c17acce4dd1c32f6bf8524686e4..104875c2654ebb6b8c981f21444eb3c06c9187db 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="#foot208"><SUP><SPAN CLASS="arabic">1</SPAN></SUP></A>,
+  HREF="#foot215"><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="315"></A>
+<DIV ALIGN="CENTER"><A NAME="fig:classhierarchy"></A><A NAME="322"></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="321"></A>
+<DD><A NAME="332"></A>
     Is the base of Ion's object system.
 
 <P>
 </DD>
 <DT><STRONG>WRegion</STRONG></DT>
-<DD><A NAME="322"></A>
+<DD><A NAME="333"></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="323"></A> is a class for
+<DD><A NAME="334"></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="324"></A> is the base class for all
+<DD><A NAME="335"></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="325"></A> is an instance of WMPlex
+<DD><A NAME="336"></A> is an instance of WMPlex
     for screens.
 
 <P>
 </DD>
 <DT><STRONG>WRootWin</STRONG></DT>
-<DD><A NAME="326"></A> is the class for
-    root windows<A NAME="242"></A> of X screens<A NAME="243"></A>.
+<DD><A NAME="337"></A> is the class for
+    root windows<A NAME="249"></A> of X screens<A NAME="250"></A>.
     It is an instance of WScreen.
     Note that an ``X screen'' or root window is not necessarily a
-    single physical screen<A NAME="245"></A> as a root window
+    single physical screen<A NAME="252"></A> as a root window
     may be split over multiple screens when ugly hacks such as 
-    Xinerama<A NAME="246"></A> are used. (Actually there can be only 
+    Xinerama<A NAME="253"></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="327"></A> is the class for frames.
+<DD><A NAME="338"></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="328"></A> is the base class for groups.
+<DD><A NAME="339"></A> is the base class for groups.
     Particular types of groups are workspaces 
-    (WGroupWS<A NAME="329"></A>)
+    (WGroupWS<A NAME="340"></A>)
     and groups of client windows
-    (WGroupCW<A NAME="330"></A>).
+    (WGroupCW<A NAME="341"></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="332"></A> is the class for tilings
+<DD><A NAME="344"></A> is the class for tilings
     of frames.
   
 </DD>
 <DT><STRONG>WSplit</STRONG></DT>
-<DD><A NAME="333"></A> (or, more specifically, classes
+<DD><A NAME="345"></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="335"></A> is a virtual base class for the
+<DD><A NAME="348"></A> is a virtual base class for the
     two classes below.
   
 </DD>
 <DT><STRONG>WEdln</STRONG></DT>
-<DD><A NAME="336"></A> is the class for the ``queries'',
+<DD><A NAME="349"></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="337"></A> implements the boxes for 
+<DD><A NAME="350"></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="278"></A> for an object is always a 
+associated to it. The parent<A NAME="285"></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="289"></A>
+<DIV ALIGN="CENTER"><A NAME="fig:parentship"></A><A NAME="296"></A>
 <TABLE>
 <CAPTION ALIGN="BOTTOM"><STRONG>Figure 2:</STRONG>
 Most common parent-child relations</CAPTION>
@@ -321,7 +321,7 @@ Most common parent-child relations</CAPTION>
 
 <P>
 WRegions have very little control over their children as a parent.
-The manager<A NAME="293"></A> WRegion has much more control over its
+The manager<A NAME="300"></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
@@ -338,7 +338,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="301"></A>
+<DIV ALIGN="CENTER"><A NAME="fig:managership"></A><A NAME="308"></A>
 <TABLE>
 <CAPTION ALIGN="BOTTOM"><STRONG>Figure 3:</STRONG>
 Most common manager-managed relations</CAPTION>
@@ -401,7 +401,7 @@ consideration:
 <P>
 <BR><HR><H4>Footnotes</H4>
 <DL>
-<DT><A NAME="foot208">... design</A><A
+<DT><A NAME="foot215">... 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