Previous Up Next

2  Preliminaries: The Ion class and object hierarchies

Although Ion does not have a truely object-oriented design -- and I, the author of this document and Ion wouldn't even like such a design -- it does have a primitive object oriented design for ''screen objects''. It is essential for the module writer to learn this object system, but it should be usefull for the person who just wants to configure key bindings to learn at least something about Ion's object hierarchy. When you know the class and object hierarchies, you know how and where the available functions can be used and how to construct more complex scripts. Therefore I suggest that you read this short chapter or at least the summary at the end of it before skipping on to the more interesting things and even trying to write custom binding configuration files.

2.1  Class hierarchy

One of the most important principles of object-oriented design methodology is inheritance -- roughly how classes (objects are instances of classes) extend on others' features. Inheritance gives rise to class hierarchy. In the case of single-inheritance this hierarchy can be expressed as a tree where the object at the root is inherited by all others below it and so on.

Figure 2.1 lists out the Ion class hierarchy and below we explain what the classes implement. If you are wondering what the ''(xyz module)'' strings in the figure are, they're related to the division of Ion into a core binary and multiple modules that implement optional features. Module support also allows implementing C-side extensions to Ion without changes to Ion's code or the need of recompiling if the operating system has decent support for dynamic linking.

    WObj
     |
     |-->WRegion
     |    |
     |    |-->WClientWin
     |    |
     |    |-->WWindow
     |    |    |
     |    |    |-->WRootWin
     |    |    |
     |    |    |-->WMPlex
     |    |    |    |
     |    |    |    |-->WScreen
     |    |    |    |
     |    |    |    |-->WGenFrame
     |    |    |         |
     |    |    |         |-->WIonFrame (ionws module)
     |    |    |         |
     |    |    |         |-->WFloatFrame (floatws module)
     |    |    |
     |    |    |-->WInput (query module)
     |    |         |
     |    |         |-->WEdln (query module)
     |    |         |
     |    |         |-->WMessage (query module)
     |    |
     |    |-->WGenWS
     |         |
     |         |-->WIonWS (ionws module)
     |         |
     |         |-->WFloatWS (floatws module)
     |
     |-->WWsSplit (ionws)

Figure 2.1: Ion class hierarchy. The string in parenthesis indicates the module in which this class is implemented if not in Ioncore.


The core classes:
WObj
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 great 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'' type WRegion; all concrete regions are objects of some class that inherits WRegion.

WClientWin
is a class for client window objects -- the objects that window managers are supposed to manage.

WWindow
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 multi-head extensions such as Xinerama are used. (Actually there can be only one WRootWin when Xinerama is used.)
WMPlex
is again a virtual 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. WMPlexes include screens and the different types of frames.

WScreen
is the class for objects corresponding to physical screens. Screens may share a root window when Xinerama multihead extensions are used as explained above.

WGenFrame
is another virtual class implementing what is common to the concrete frame classes but not all WMPlexes. While most Ion's objects have no graphical presentation, frames are basically the decorations around client windows (borders, tabs).

WGenWS
is a light virtual base class for different types of workspaces.
Classes implemented by the ionws module:
WIonWS
is the class for the usual tiled workspaces.
WIonFrame
implements the style of frames seen on WIonWSs.
WWsSplit
is an object internal to WIonWS implementation and stores the tree structure of the workspaces.
Classes implemented by the floatws module:
WFloatWS
is the class for the conventional workspaces where frames and other objects are allowed to ''float'' around.
WFloatFrame
implements the frames seen on WFloatWSs decorated in the PWM style.
Classes implemented by the query module:
WInput
is a virtual base class for the two classes below.
WEdln
is the class for the ''queries'', the text inputs that usually appear at bottoms of frames and sometimes screens. Quiries are the functional equivalent of ''mini buffers'' in many text editors.
WMessage
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.

2.2  Object hierarchies: WRegion parents and managers

Each object of type WRegion has a parent and possibly a manager 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. There is generally very few restrictions other than the above on the parent---child relation but the most common is as described in Figure 2.2.

    WRootWins
     |
     |-->WScreens
          |
          |-->WIonWS:s and WFloatWS:s
          |
          |-->WClientWins in full screen mode
          |
          |-->WIonFrames and WFloatFrames
               |
               |-->WClientWins, including transients
               |
               |-->a possible WEdln or WMessage

Figure 2.2: 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 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 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.

    WRootWins
     |
     |-->WScreens
          |
          |-->full screen WClientWins
          |    |
          |    |-->transient WClientWins (dialogs)
          |
          |-->WIonWSs
          |    |
          |    |-->WIonFrames
          |         |
          |         |-->WClientWins
          |         |    |
          |         |    |-->transient WClientWins (dialogs)
          |         |
          |         |-->a possible WEdln or WMessage
          |
          |-->WFloatWSs
               |
               |-->WFloatFrames
                    |
                    |-->WClientWins
                    |
                    |-->a possible WEdln or WMessage

Figure 2.3: Most common manager--managed relations


Note how the WClientWins managed by WFloatFrames don't have transients managed by them. This is because WFloatWSs choose to handle transients differently (transients are put in separate frames like normal windows; in the future they should be stacked above the frame containing the transient_for window).

2.3  Summary

In the standard setup, keeping queries, messages and menus out of consideration:
Previous Up Next