The purpose of this chapter to explain some of key concepts and relations you need to understand before reading the following chapters. These include modules explained in section 2.1 and the Ion class and object hierarchies, section 2.2.
Ion has been designed so that the 'ion' executable only implements some basic services on top of which very different kinds of window managers could be build by loading the appropriate 'modules'. On modern system these modules are simply dynamically loaded .so libraries. On more primitive systems, or if you want to squeeze total size of the executable and libraries, the modules can optionally be statically linked to the main binary, but must nevertheless be loaded with the dopath function. Modules may also include Lua code.
If no modules are loaded, all client windows appear in full screen mode. To get better window management support, one or more workspace modules should be loaded. Currently Ion provides the following modules:
So-called drawing engines are also implemented as a modules, but they are not discussed here; see chapter 4.
The stock configuration for the 'ion3' executable loads all of the modules mentioned above except mod_dock and filemod_mgmtmode. The stock configuration for the 'pwm3' executable (which differs from the 'ion3' executable in a few configuration details, such as Xinerama usage) loads another set of modules.
While Ion does not not have a truly object-oriented design 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 other things.
It is essential for the module writer to learn this object system, but also people who write their own binding configuration files necessarily come into contact with the class and object hierarchies - you need to know which binding setup routines apply where, and what functions can be used as handlers in which bindings. It is the purpose of this section to attempt to explain these hierarchies. If you do not wish the read the full section, at least read the summary at the end of it, so that you understand the very basic relations.
For simplicity we consider only the essential-for-basic-configuration Ioncore, mod_tiling and mod_query classes. See Appendix B for the full class hierachy visible to Lua side.
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 class 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 features of Ion the classes implement.
Obj |-->WRegion | |-->WClientWin | |-->WWindow | | |-->WMPlex | | | |-->WFrame | | | |-->WScreen | | | |-->WRootWin | | |-->WInput (mod_query) | | |-->WEdln (mod_query) | | |-->WMessage (mod_query) | |-->WGroup | | |-->WGroupWS | | |-->WGroupCW | |-->WTiling (mod_tiling) |-->WSplit (mod_tiling) |
The core classes:
Classes implemented by the mod_tiling module:
Classes implemented by the mod_query module:
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.
WRootWins |-->WScreens |-->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 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 |-->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 |
Note that a workspace can manage another workspace. This can be achieved with the attach_new function, and allows you to nest workspaces as deep as you want.
In the standard setup, keeping queries, messages and menus out of consideration: