X-Git-Url: https://git.decadent.org.uk/gitweb/?p=ion3-doc.git;a=blobdiff_plain;f=ionconf%2Fnode3.html;fp=ionconf%2Fnode3.html;h=23a94d2bb491a7ad5e51c1d4c36bec4f42641d99;hp=8af0cedc0121992cabaee5f39bf8cdc959d653ff;hb=e3c5d80a031edf9fa8787d92ecf03acb0cfa2316;hpb=4e87ab4e15972ded93606084111ff86ae7e9a1af diff --git a/ionconf/node3.html b/ionconf/node3.html index 8af0ced..23a94d2 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="#foot314">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.

-

+
@@ -414,7 +414,7 @@ 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 @@ -431,7 +431,7 @@ a manager, but all have a parent-a screen if not anything else.

-

+
Figure 2.2: Most common parent-child relations
@@ -494,7 +494,7 @@ consideration:


Footnotes

-
... design... design2.1
the author doesn't like such artificial designs
Figure 2.3: Most common manager-managed relations