While Ion does not not have a truly object-oriented design ¹, + HREF="#foot208">¹, things that appear on the computer screen are, however, quite -naturally expressed as such ''objects''. Therefore Ion implements +naturally expressed as such ``objects''. Therefore Ion implements a rather primitive OO system for these screen objects and some other things. @@ -107,7 +107,7 @@ basic relations.

For simplicity we consider only the essential-for-basic-configuration Ioncore, mod_tiling and mod_query classes. -See Appendix

for the full class hierachy visible +See Appendix

for the full class hierarchy visible to Lua side.

Figure 1: Partial Ioncore, mod_tiling and mod_query @@ -140,16 +140,16 @@ Partial Ioncore, mod_tiling and +

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 operates on these instead of more specialised classes, WRegion - is a ''virtual'' base class in that there are no objects of ''pure'' + is a ``virtual'' base class in that there are no objects of ``pure'' type WRegion; all concrete regions are objects of some class that inherits WRegion.

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). -

WRootWin

is the class for - root windows of X screens. - Note that an ''X screen'' or root window is not necessarily a - single physical screen as a root window - may be split over multiple screens when hacks such as - Xinerama are used. (Actually there can be only - one root window when Xinerama is used.) -

WMPlex

is a base class for all regions that''multiplex'' +

is a base class for all regions that ``multiplex'' other regions. This means that of the regions managed by the multiplexer, - only one can be displayed at a time. Classes that inhereit WMPlex - include screens and frames. + only one can be displayed at a time.

WScreen

is the class for objects - corresponding to physical screens. Screens may share a root - window when the Xinerama extension is used as explained above. +

is an instance of WMPlex + for screens. + +

WRootWin

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 + may be split over multiple screens when ugly hacks such as + Xinerama are used. (Actually there can be only + one root window when Xinerama is used.)

WFrame

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). +

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).

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).

@@ -240,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.

@@ -256,26 +255,26 @@ 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 + 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.

-There are also some other ''proxy'' classes that do not refer +There are also some other ``proxy'' classes that do not refer to objects on the screen. The only important one of these for basic configuration is WMoveresMode that is used for binding callbacks in the move and resize mode. @@ -292,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. @@ -302,36 +301,34 @@ Figure 2.

Figure 2: Most common parent-child relations

     WRootWins
-     |-->WScreens
-          |-->WGroupWSs
-          |-->WTilings
-          |-->WClientWins in full screen mode
-          |-->WFrames
-               |-->WGroupCWs
-               |-->WClientWins
-               |-->WFrames for transients
-               |-->a possible WEdln or WMessage
+     |-->WGroupWSs
+     |-->WTilings
+     |-->WClientWins in full screen mode
+     `-->WFrames
+          |-->WGroupCWs
+          |-->WClientWins
+          |-->WFrames for transients
+          `-->a possible WEdln or WMessage

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 3. Note that sometimes -the parent and manager are the same object and not all objects may have -a manager (e.g. the dock in the dock module at the time of writing this) -but all have a parent-a screen if not anything else. +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.

@@ -341,26 +338,25 @@ but all have a parent-a screen if not anything else.

Figure 3: Most common manager-managed relations

     WRootWins
-     |-->WScreens
-          |-->WGroupCWs for full screen WClientWins
-          |    |-->WClientWins
-          |    |-->WFrames for transients (dialogs)
-          |         |--> WClientWin
-          |-->WGroupWSs for workspaces
-          |    |-->WTiling
-          |    |    |-->WFrames
-          |    |    |    |-->WGroupCWs (with contents as above)
-          |    |    |-->possibly a WStatusBar or WDock
-          |    |-->WFrames for floating content
-          |    |-->possibly a WEdln, WMessage or WMenu
-          |    |-->possibly a WStatusBar or WDock (if no tiling)
-          |-->WFrames for sticky stuff, such as the scratchpad
+     |-->WGroupCWs for full screen WClientWins
+     |    |-->WClientWins
+     |    `-->WFrames for transients (dialogs)
+     |         `--> WClientWin
+     |-->WGroupWSs for workspaces
+     |    |-->WTiling
+     |    |    |-->WFrames
+     |    |    |    `-->WGroupCWs (with contents as above)
+     |    |    `-->possibly a WStatusBar or WDock
+     |    |-->WFrames for floating content
+     |    |-->possibly a WEdln, WMessage or WMenu
+     |    `-->possibly a WStatusBar or WDock (if no tiling)
+     `-->WFrames for sticky stuff, such as the scratchpad

@@ -405,7 +401,7 @@ consideration:

Footnotes

... design ... design ¹: the author doesn't like such artificial designs @@ -413,31 +409,31 @@ consideration: