X-Git-Url: https://git.decadent.org.uk/gitweb/?a=blobdiff_plain;ds=sidebyside;f=ionconf%2Fnode6.html;h=200471fca2d1391051b539c7480523b007e0dec4;hb=ff50b32b3f2fb8bebd445decad84eae135113d0e;hp=b1bbe8bf3fe0cb8a6c2e9ff4742a04ed29990215;hpb=6e84dc8312f2fdb5b8b7467a0279afd5b2df107f;p=ion3-doc.git diff --git a/ionconf/node6.html b/ionconf/node6.html index b1bbe8b..200471f 100644 --- a/ionconf/node6.html +++ b/ionconf/node6.html @@ -28,31 +28,31 @@ original version by: Nikos Drakos, CBLU, University of Leeds
@@ -61,20 +61,20 @@ original version by: Nikos Drakos, CBLU, University of Leeds SubsectionsThis chapter documents some additional features of the Ion configuration and scripting interface that can be used for more advanced scripting than -the basic configuration exlained in chapter 3. +the basic configuration explained in chapter 3.
@@ -101,16 +101,16 @@ the basic configuration exlained in chapter 3
Hooks are lists of functions to be called when a certain event occurs.
-There are two types of them; normal and ''alternative'' hooks. Normal
+There are two types of them; normal and ``alternative'' hooks. Normal
hooks do not return anything, but alt-hooks should return a boolean
-indicating whether it handled its assigned task succesfully. In the case
+indicating whether it handled its assigned task successfully. In the case
that true is returned, remaining handlers are not called.
Hook handlers are registered by first finding the hook
-with ioncore.get_hook and then calling WHook.add
-on the (succesfull) result with the handler as parameter. Similarly
-handlers are unregistered with WHook.remove. For example:
+with ioncore.get_hook and then calling WHook.add
+on the (successful) result with the handler as parameter. Similarly
+handlers are unregistered with WHook.remove. For example:
In this example the hook handler has no parameters, but many hook
handlers do. The types of parameters for each hook are listed in
-the hook reference, section 6.8.
+the hook reference, section 6.9.
-Note that many of the hooks are called in ''protected mode'' and can not
-use any functions that modify Ion's internal state. TODO: More detailed
-documentation when this is final.
+Note that many of the hooks are called in ``protected mode'' and can not
+use any functions that modify Ion's internal state.
@@ -142,7 +141,7 @@ documentation when this is final.
-All Ion objects are passed to Lua scriptss as 'userdatas', and you may
+All Ion objects are passed to Lua scripts as 'userdatas', and you may
safely store such object references for future use. The C-side object
may be destroyed while Lua still refers to the object. All exported
functions gracefully fail in such a case, but if you need to explicitly
@@ -180,11 +179,11 @@ end
If you want to a single non-WClientWin region with an exact known
name, use ioncore.lookup_region. If you want a list of all regions,
-use ioncore.region_list. Both functions accept an optional argument
+use ioncore.region_list. Both functions accept an optional argument
that can be used to specify that the returned region(s) must be of a more
specific type. Client windows live in a different namespace and for them
you should use the equivalent functions ioncore.lookup_clientwin
-and ioncore.clientwin_list.
+and ioncore.clientwin_list.
To get the name of an object, use WRegion.name. Please be
@@ -202,13 +201,16 @@ region, use WRegion.set_name
It is possible to write more complex winprop selection routines than
those described in section 3.5. To match a particular
winprop using whatever way you want to, just set the match
-field of the winprop to a function that receives the client window
-as its sole parameter, and that returns true if the winprop
-matches, and false otherwise.
+field of the winprop to a function that receives the as its parameters
+the triple (prop, cwin, id), where prop is the table for
+the winprop itself, cwin is the client window object,
+and id is the WClientWin.get_ident result.
+The function should return true if the winprop matches,
+and false otherwise. Note that the match function
+is only called after matching against class/role/instance.
-The class, instance and role properties can be obtained with
-WClientWin.get_ident, and the title with WRegion.name.
+The title of a client window can be obtained with WRegion.name.
If you want to match against (almost) arbitrary window properties,
have a look at the documentation for the following functions, and
their standard Xlib counterparts: ioncore.x_intern_atom
@@ -219,8 +221,10 @@ and ioncore.x_get_text_p
-
@@ -228,11 +232,11 @@ All statusbar meters that do not monitor the internal state of Ion should
go in the separate ion-statusd program.
-Whenever the user requests a meter %foo or %foo_bar to be
-inserted in a statusbar, mod_statusbar asks ion-statusd to
-load statusd_foo.lua on its search path (same as that for Ion-side
+Whenever the user requests a meter `%foo' or `%foo_bar' to
+be inserted in a statusbar, mod_statusbar asks ion-statusd
+to load statusd_foo.lua on its search path (same as that for Ion-side
scripts). This script should then supply all meters with the initial part
-'foo'.
+`foo'.
To provide this value, the script should simply call statusd.inform
@@ -241,11 +245,11 @@ Additionally the script should provide a 'template' for the meter to
facilitate expected width calculation by mod_statusbar, and
may provide a 'hint' for colour-coding the value. The interpretation
of hints depends on the graphical style in use, and currently the
-stock styles support the normal, important and
-critical hints.
+stock styles support the `normal', `important' and
+`critical' hints.
-In our example of the 'foo monitor', at script init we might broadcast
+In our example of the 'foo monitor', at script initialisation we might broadcast
the template as follows:
@@ -319,31 +323,31 @@ local settings=table.join(statusd.get_config("foo"), defaults)
@@ -122,12 +122,11 @@ ioncore.get_hook("ioncore_snapshot_hook"):add(
-5.4 Writing ion-statusd monitors
+
+
+
+5.4 Writing ion-statusd monitors