X-Git-Url: https://git.decadent.org.uk/gitweb/?a=blobdiff_plain;ds=sidebyside;f=doc%2Fionnotes%2Fnode2.html;fp=doc%2Fionnotes%2Fnode2.html;h=0000000000000000000000000000000000000000;hb=a6561c9679cd701b0d50c3cfd44e4664f7df2b2f;hp=4996b37b15ed292b2ddf3adb8d9f4a33b8f1a229;hpb=cd09055902de482a1be019bf4b4efdae64c98d35;p=ion3.git diff --git a/doc/ionnotes/node2.html b/doc/ionnotes/node2.html deleted file mode 100644 index 4996b37..0000000 --- a/doc/ionnotes/node2.html +++ /dev/null @@ -1,444 +0,0 @@ - - - - -
--While Ion does not not have a truly object-oriented design -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 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 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 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: - -
- -
-