X-Git-Url: https://git.decadent.org.uk/gitweb/?p=ion3-doc.git;a=blobdiff_plain;f=ionnotes%2Fnode2.html;fp=ionnotes%2Fnode2.html;h=104875c2654ebb6b8c981f21444eb3c06c9187db;hp=db367a5e33c35c17acce4dd1c32f6bf8524686e4;hb=e3c5d80a031edf9fa8787d92ecf03acb0cfa2316;hpb=4e87ab4e15972ded93606084111ff86ae7e9a1af diff --git a/ionnotes/node2.html b/ionnotes/node2.html index db367a5..104875c 100644 --- a/ionnotes/node2.html +++ b/ionnotes/node2.html @@ -87,7 +87,7 @@ original version by: Nikos Drakos, CBLU, University of Leeds

While Ion does not not have a truly object-oriented design 1, + HREF="#foot215">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 @@ -128,7 +128,7 @@ implement.

-

+
Figure 1: Partial Ioncore, mod_tiling and mod_query @@ -160,13 +160,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 @@ -178,14 +178,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). @@ -199,25 +199,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). @@ -225,11 +225,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).
@@ -239,12 +239,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.
@@ -255,19 +255,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.
@@ -291,7 +291,7 @@ binding callbacks in the move and resize mode. 1.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. @@ -301,7 +301,7 @@ Figure 2.

-

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

-

+
Figure 2: Most common parent-child relations
@@ -401,7 +401,7 @@ consideration:



Footnotes

-
... design... design1
the author doesn't like such artificial designs
Figure 3: Most common manager-managed relations