-
-
-
-
-
-
-
-
-- Next: 3. Basic configuration - Up: Configuring and extending Ion3 - Previous: 1. Introduction - Contents - Index -
-
-
-
-
-
-
-
-
-
--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. -The stock configuration for the pwm3 executable (which differs -from the ion3 executable in a few configuration details) -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 hierarchy 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: - -
- -
-
-
-
-
-
-
-
-
-
-