X-Git-Url: https://git.decadent.org.uk/gitweb/?a=blobdiff_plain;f=ionconf%2Fnode3.html;h=dbe890afa8e58017034789ff357bfdac16f8775e;hb=HEAD;hp=23a94d2bb491a7ad5e51c1d4c36bec4f42641d99;hpb=e3c5d80a031edf9fa8787d92ecf03acb0cfa2316;p=ion3-doc.git
diff --git a/ionconf/node3.html b/ionconf/node3.html
index 23a94d2..dbe890a 100644
--- a/ionconf/node3.html
+++ b/ionconf/node3.html
@@ -180,7 +180,7 @@ loads another set of modules.
While Ion does not not have a truly object-oriented design
2.1,
+ HREF="#foot303">2.1,
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
@@ -221,7 +221,7 @@ implement.
-
+
Figure 2.1:
Partial Ioncore, mod_tiling and mod_query
@@ -253,13 +253,13 @@ The core classes:
- Obj
--
+
-
Is the base of Ion's object system.
- WRegion
--
+
-
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
@@ -271,14 +271,14 @@ The core classes:
- WClientWin
-- is a class for
+
- is a class for
client window objects, the objects that window managers are
supposed to manage.
- WWindow
-- is the base class for all
+
- is the base class for all
internal objects having an X window associated to them
(WClientWins also have X windows associated to them).
@@ -292,25 +292,25 @@ The core classes:
- WScreen
-- is an instance of WMPlex
+
- is an instance of WMPlex
for screens.
- WRootWin
-- is the class for
- root windows of X screens.
+
- is the class for
+ root windows of X screens.
It is an instance of WScreen.
Note that an ``X screen'' or root window is not necessarily a
- single physical screen as a root window
+ single physical screen as a root window
may be split over multiple screens when ugly hacks such as
- Xinerama are used. (Actually there can be only
+ Xinerama are used. (Actually there can be only
one root window when Xinerama is used.)
- WFrame
-- is the class for frames.
+
- 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).
@@ -318,11 +318,11 @@ The core classes:
- WGroup
-- is the base class for groups.
+
- is the base class for groups.
Particular types of groups are workspaces
- (WGroupWS)
+ (WGroupWS)
and groups of client windows
- (WGroupCW).
+ (WGroupCW).
@@ -332,12 +332,12 @@ Classes implemented by the mod_tiling module:
- WTiling
-- is the class for tilings
+
- is the class for tilings
of frames.
- WSplit
-- (or, more specifically, classes
+
- (or, more specifically, classes
that inherit it) encode the WTiling tree structure.
@@ -348,19 +348,19 @@ Classes implemented by the mod_query module:
- WInput
-- is a virtual base class for the
+
- is a virtual base class for the
two classes below.
- WEdln
-- is the class for the ``queries'',
+
- 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.
- WMessage
-- implements the boxes for
+
- 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.
@@ -384,7 +384,7 @@ binding callbacks in the move and resize mode.
2.2.2.1 Parent-child relations
Each object of type WRegion has a parent and possibly a manager
-associated to it. The parent for an object is always a
+associated to it. The parent 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.
@@ -394,7 +394,7 @@ Figure 2.2.
-
+
Figure 2.2:
Most common parent-child relations
@@ -414,14 +414,15 @@ Most common parent-child relations
WRegions have very little control over their children as a parent.
-The manager WRegion has much more control over its
+The manager 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 2.3. 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.
@@ -431,7 +432,7 @@ a manager, but all have a parent-a screen if not anything else.
-
+
Figure 2.3:
Most common manager-managed relations
@@ -494,7 +495,7 @@ consideration:
Footnotes
-- ... design... design2.1
- the author doesn't like such artificial designs