X-Git-Url: https://git.decadent.org.uk/gitweb/?p=ion3-doc.git;a=blobdiff_plain;f=ionconf%2Fnode4.html;fp=ionconf%2Fnode4.html;h=4eaa00e82c046a51c49d5ab6d561f0cf85f094af;hp=0aab7ccf5ef6e25be645d51f6ef38fe919a96ca4;hb=da1e04def26932e7f91a2106c885142e7fafe59b;hpb=a35ba2541b8601953ae94f779a85ae70de19cd11
diff --git a/ionconf/node4.html b/ionconf/node4.html
index 0aab7cc..4eaa00e 100644
--- a/ionconf/node4.html
+++ b/ionconf/node4.html
@@ -28,31 +28,31 @@ original version by: Nikos Drakos, CBLU, University of Leeds
@@ -61,60 +61,77 @@ original version by: Nikos Drakos, CBLU, University of Leeds
Subsections
@@ -140,8 +157,8 @@ configuration file ion.lua is provided in section
3.2.
How keys and mouse action are bound to functions is described in detail
in 3.3 and in section 3.5 winprops are
-explained. For a reference on exported functions, see section
-6.
+explained. Finally, the statusbar is explained in 3.6.
+For a reference on exported functions, see section 6.
@@ -155,9 +172,9 @@ explained. For a reference on exported functions, see section
Ion3, to which document applies, stores its stock configuration files in
/usr/local/etc/ion3/ unless you, the OS package maintainer or
whoever installed the package on the system has modified the variables
-PREFIX or
-ETCDIR in
-system.mk before compiling Ion.
+PREFIX or
+ETCDIR in
+system.mk before compiling Ion.
In the first case you probably know where to find the files and in
the other case the system administrator or the OS package maintainer
should have provided documentation to point to the correct location.
@@ -177,7 +194,7 @@ for a file, if no extension or path component is given, compiled .lua files.
-All the configuration files are named cfg_*.lua with the ''*''
+All the configuration files are named cfg_*.lua with the ``*''
part varying. The configuration file for each module mod_modname is
cfg_modname.lua, with modname varying by the module in
question. The following table summarises these and other configuration
@@ -232,20 +249,22 @@ file. Some basic 'feel' settings are usually configured there and
the necessary modules and other configuration files configuring some
more specific aspects of Ion are loaded there. In this section we
take a walk through the stock cfg_ion.lua.
-Notice that most of the settings are commented-out (- is a
+Notice that most of the settings are commented-out (-- is a
line comment in Lua) in the actual file, as they're the defaults
nevertheless.
-The first thing one in the file is to set
+The first thing done in the file, is to set
META="Mod1+"
ALTMETA=""
These settings cause most of Ion's key bindings to use Mod1 as the
-modifier key. If ALTMETA is set, it is used as modifier for the keys
-that don't normally use a modifier. for details on modifiers and key
-binding setup in general see section 3.3.
+modifier key. If ALTMETA is set, it is used as modifier for the
+keys that don't normally use a modifier. Note that these two are Lua
+variables used in the configuration files only, and not Ion settings.
+For details on modifiers and key binding setup in general, see section
+3.3.
Next we do some basic feel configuration:
@@ -283,7 +302,7 @@ for ioncore.set for details.
As a next step, in the actual cfg_ion.lua file, we load
-cfg_defaults.lua. However, it is merely a conveniency file for
+cfg_defaults.lua. However, it is merely a convenience file for
doing exactly what we will going through below, and what is commented
out in the actual file. If you do not want to load what
cfg_defaults.lua loads, just comment out the corresponding
@@ -301,8 +320,8 @@ dopath("cfg_layouts")
Most bindings and menus are defined in cfg_ioncore.lua.
Details on making such definitions follow in sections 3.3
and 3.4, respectively.
-some kludges or ''winprops'' to make some applications behave better
-under Ion are colledted in cfg_kludges.lua; see section
+some kludges or ``winprops'' to make some applications behave better
+under Ion are collected in cfg_kludges.lua; see section
3.5 for details. In addition to these, this file
lists quite a few statements of the form
@@ -348,7 +367,7 @@ loaded prior to defining any module-specific bindings.
Bindings are defined by calling the function
-defbindings with the ''context'' of the
+defbindings with the ``context'' of the
bindings and the a table of new bindings to make. The context is simply
string indicating one of the classes of regions (or modes such as
WMoveresMode) introduced in section 2.2, and fully
@@ -365,7 +384,7 @@ defbindings("WFrame", {
There has been some confusion among users about the need to define the
-''context'' for each binding, so let me try to explain this design
+``context'' for each binding, so let me try to explain this design
decision here. The thing is that if there was a just a simple 'bind this
key to this action' method without knowledge of the context, some
limitations would have to be made on the available actions and writing
@@ -373,31 +392,37 @@ custom handlers would be more complicated. In addition one may want to
bind the same function to different key for different types of objects.
Indeed, the workspace and frame tab switching functions are the same both
classes being based on WMPlex, and in the stock configuration the
-switch to :th workspaces is bound to Mod1+n while the switch to
-:th tab is bound to the sequence Mod1+k n.
-
-
-Currently known ''contexts'' include:
-WScreen,
-WMPlex,
-WMPlex.toplevel,
-WFrame,
-WFrame.toplevel,
-WFrame.floating,
-WFrame.tiled,
-WFrame.transient,
-WMoveresMode,
-WGroup,
-WGroupCW,
-WGroupWS,
-WClientWin,
-WTiling, and
-WStatusBar.
+switch to 
:th workspaces is bound to Mod1+n while the switch to
+:th tab is bound to the sequence Mod1+k n.
+
+
+Currently known contexts include:
+`WScreen',
+`WMPlex',
+`WMPlex.toplevel',
+`WFrame',
+`WFrame.toplevel',
+`WFrame.floating',
+`WFrame.tiled',
+`WFrame.transient',
+`WMoveresMode',
+`WGroup',
+`WGroupCW',
+`WGroupWS',
+`WClientWin',
+`WTiling', and
+`WStatusBar'.
Most of these should be self-explanatory, corresponding to objects
-of class with the same name. The ones with .toplevel suffix
-refer to screens and ''toplevel'' frames, i.e. frames that are
-not used for transient windows. Likewise .transient refers
-to frames in transient mode, and .tiled and .floating
+of class with the same name. The ones with `.toplevel' suffix
+refer to screens and ``toplevel'' frames, i.e. frames that are
+not used for transient windows. Likewise `.transient' refers
+to frames in transient mode, and `.tiled' and `.floating'
to frames in, respectively, tiled and floating modes.
@@ -422,9 +447,9 @@ gets to handle the action.
Unlike in Ion2, in Ion3 binding handlers are not normally passed as
-''anonymous functions'', although this is still possible. The preferred
-method now is to pass the code of the handler as a string. Two special
-variables are available in this code. These are
+``anonymous functions'', although this is still possible. The preferred
+method now is to pass the code of the handler as a string. Two following
+special variables are available in this code.
@@ -445,13 +470,14 @@ variables are available in this code. These are
| _chld |
Object corresponding to the currently active child window of the
- object referred to by _. |
+ object referred to by _. This should seldom be needed.
-For example, supposing '_' is a WFrame, the following
-handler should move the active window to the right, if possible:
+For example, supposing _ (underscore) is a WFrame, the
+following handler should move the active window to the right, if
+possible:
@@ -466,7 +492,7 @@ handler should move the active window to the right, if possible:
To suppress error messages, each binding handler may also be accompanied
-by a ''guard'' expression that blocks the handler from being called when
+by a ``guard'' expression that blocks the handler from being called when
the guard condition is not met. Currently the following guard expressions
are supported (for both _sub and _chld):
@@ -475,10 +501,10 @@ are supported (for both _sub and _chld):
| Guard |
Description |
-| "_sub:non-nil" |
+
| `_sub:non-nil' |
The _sub parameter must be set. |
-| "_sub:SomeClass" |
+
| `_sub:SomeClass' |
The _sub parameter must be member
of class SomeClass. |
@@ -501,36 +527,39 @@ functions.
Key presses:
-- kpress(keyspec, handler [, guard]),
+
- kpress, and
+ kpress_wait(keyspec, handler [, guard]).
-- kpress_wait(keyspec, handler [, guard]) and
+
- submap(keyspec, { ... more key bindings ... }).
-- submap(keyspec, { ... more key bindings ... }).
+
- submap_enter, and
+ submap_wait(handler [, guard]).
Mouse actions:
-- mclick(buttonspec, handler [, guard]),
-
-- mdblclick(buttonspec, handler [, guard]),
-
-- mpress(buttonspec, handler [, guard]) and
-
-- mdrag(buttonspec, handler [, guard]).
+
- mclick,
+ mdblclick,
+ mpress, and
+ mdrag(buttonspec, handler [, guard]).
The actions that most of these functions correspond to should be clear
-and as explained in the reference, kpress_wait is simply
-kpress with a flag set instructing Ioncore wait for all
-modifiers to be released before processing any further actions.
+and as explained in the reference, kpress_wait is simply
+kpress with a flag set instructing Ioncore wait for
+all modifiers to be released before processing any further actions.
This is to stop one from accidentally calling e.g.
-WRegion.rqclose multiple times in a row. The submap
-function is used to define submaps or ''prefix maps''. The second
-argument to this function is table listing the key press actions
-(kpress) in the submap
+WRegion.rqclose multiple times in a row. The
+submap function is used to define submaps or
+``prefix maps''. The second argument to this function is table listing
+the key press actions (kpress) in the submap.
+The submap_enter handler is called when the submap
+is entered, in which this handler is defined. Likewise, the
+submap_wait handler is called when all modifiers
+have been released while waiting for further key presses in the submap.
The parameters keyspec and buttonspec are explained below
@@ -583,36 +612,35 @@ defbindings("WFrame", {
As seen above, the functions that create key binding specifications require
a keyspec argument. This argument should be a string containing the
name of a key as listed in the X header file keysymdef.h3.1 without the XK_ prefix.
-
+ HREF="#foot876">3.1 without the XK_ prefix.
+
Most of the key names are quite intuitive while some are not. For example,
the Enter key on the main part of the keyboard has the less common
name Return while the one the numpad is called KP_Enter.
-The keyspec string may optionally have multiple ''modifier'' names
+The keyspec string may optionally have multiple ``modifier'' names
followed by a plus sign (+) as a prefix. X defines the following
modifiers:
-
+
+
Shift, Control, Mod1 to Mod5,
AnyModifier and Lock.
-
-
-
-
-
-
-
+
+
+
+
+
X allows binding all of these modifiers to almost any key and while this
list of modifiers does not explicitly list keys such as
-Alt that are common on modern keyboards, such
+Alt that are common on modern keyboards, such
keys are bound to one of the ModN. On systems running XFree86
Alt is usually Mod1. On Suns Mod1 is the diamond key
-and Alt something else. One of the ''flying window'' keys on so
+and Alt something else. One of the ``flying window'' keys on so
called Windows-keyboards is probably mapped to Mod3 if you have
-such a key. Use the program xmodmap
+such a key. Use the program xmodmap
to find out what exactly is bound where.
@@ -623,11 +651,14 @@ specified modifiers in nested regions. For this reason, Ion recognises
default.
-Ion ignores the Lock modifier and any ModN ()
-bound to NumLock or
-ScrollLock
+Ion ignores the Lock modifier and any ModN (
)
+bound to NumLock or
+ScrollLock
by default because such3.2 locking keys may otherwise
+ HREF="#foot855">3.2 locking keys may otherwise
cause confusion.
@@ -640,12 +671,12 @@ cause confusion.
Button specifications are similar to key definitions but now
instead of specifying modifiers and a key, you specify modifiers
and one of the button names Button1 to
-Button5. Additionally the
+Button5. Additionally the
specification may end with an optional area name following an @-sign.
Only frames currently support areas, and the supported values in this
case are
-"border", "tab", "empty_tab", "client" and
-nil (for the whole frame).
+`border', `tab', `empty_tab', `client'
+and nil (for the whole frame).
For example, the following code binds dragging a tab with the first
@@ -667,7 +698,7 @@ defbindings("WFrame", {
The default binding configuration contains references to the variables
META and ALTMETA instead of directly using the default
-values of "Mod1+" and "" (nothing). As explained in
+values of `Mod1+' and `' (nothing). As explained in
section 3.2, the definitions of these variables
appear in cfg_ion.lua. This way you can easily change the the
modifiers used by all bindings in the default configuration without
@@ -691,10 +722,10 @@ to it is available virtually everywhere.
-
-
-
-
+
+
+
+
In the stock configuration file setup, menus are defined in the file
cfg_menus.lua as previously mentioned. The mod_menu module
must be loaded for one to be able to define menus, and this is done with
@@ -743,24 +774,24 @@ just like the menus defined as above.
| Menu name |
Description |
-| windowlist |
+
| `windowlist' |
List of all client windows. Activating an entry jumps to that window. |
-| workspacelist |
+
| `workspacelist' |
List of all workspaces. Activating an entry jumps to that workspaces. |
-| focuslist |
+
| `focuslist' |
List of client windows with recent activity in them, followed by
previously focused client windows. |
-| focuslist_ |
+
| `focuslist_' |
List of previously focused client windows. |
-| stylemenu |
+
| `stylemenu' |
List of available look_*.lua style files. Activating an entry
loads that style and ask to save the selection. |
-| ctxmenu |
+
| `ctxmenu' |
Context menu for given object. |
@@ -772,7 +803,7 @@ just like the menus defined as above.
-The ''ctxmenu'' is a special menu that is assembled from a defined context
+The ``ctxmenu'' is a special menu that is assembled from a defined context
menu for the object for which the menu was opened for, but also includes
the context menus for the manager objects as submenus.
@@ -793,9 +824,9 @@ defctxmenu("WFrame", {
-Some of the same ''modes'' as were available for some bindings
-may also be used: WFrame.tiled, WFrame.floating,
-and WFrame.transient.
+Some of the same ``modes'' as were available for some bindings
+may also be used: `WFrame.tiled', `WFrame.floating',
+and `WFrame.transient'.
@@ -828,10 +859,7 @@ handlers (and elsewhere):
| mod_menu.grabmenu |
A special version of mod_menu.menu that grabs the keyboard
and is scrolled with a given key until all modifiers have been released,
- after which the selected entry is activated. This function is meant to
- be used for implementing, for example, Win***s-style Alt-Tab
- handling.3.3 |
+ after which the selected entry is activated.
@@ -859,7 +887,7 @@ defbindings("WFrame", {
-The so-called ''winprops'' can be used to change how
+The so-called ``winprops'' can be used to change how
specific windows are handled and to set up some kludges to deal with
badly behaving applications. They are defined by calling the function
defwinprop with a table containing the properties to set and the
@@ -877,7 +905,7 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
+
Set this to true for Acrobat Reader. It has an annoying
habit of trying to manage its dialogs instead of setting them as
transients and letting the window manager do its job, causing
@@ -895,7 +923,7 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
+
Set this to open the window in a floating frame, when
in a group.
@@ -910,7 +938,7 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
+
Should the window be initially in full screen mode?
@@ -924,7 +952,7 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
+
Should configure requests on the window be ignored?
Only has effect on floating windows.
@@ -939,7 +967,7 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
+
Ignore extended WM hints _NET_ACTIVE_WINDOW request.
@@ -953,7 +981,7 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
+
Should a newly created client window always be made
active, even if the allocated frame isn't.
@@ -968,7 +996,7 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
+
If the region specified by target winprop does not exist
(or that winprop is not set), create a new workspace using the
previously stored layout (see ioncore.deflayout) named by
@@ -987,7 +1015,7 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
+
Discard this winprop after first use.
@@ -1001,11 +1029,11 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
+
Put the window in the statusbar, in the named tray component,
- (The default tray component is called simply "systray",
+ (The default tray component is called simply `systray',
and others you give names to in your custom template, always
- prefixed by "systray_".
+ prefixed by `systray_'.
@@ -1018,7 +1046,7 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
+
Should a newly mapped client window be switched to within
its frame.
@@ -1033,7 +1061,7 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
+
The name of an object (workspace, frame) that should manage
windows of this type. See also new_group.
@@ -1048,11 +1076,11 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
- "normal": No change in behaviour. "current":
+
+ `normal': No change in behaviour. `current':
The window should be thought of as a transient for the current
active client window (if any) even if it is not marked as a
- transient by the application. "off": The window should
+ transient by the application. `off': The window should
be handled as a normal window even if it is marked as a
transient by the application.
@@ -1067,7 +1095,7 @@ usual method of identifying windows, and how to obtain this information.
Description:
-
+
Should frames be made transparent when this window is selected?
@@ -1082,15 +1110,15 @@ usual method of identifying windows, and how to obtain this information.
Additionally, the winprops
-max_size,
-min_size,
-aspect,
-resizeinc,
+max_size,
+min_size,
+aspect,
+resizeinc,
and
-ignore_max_size,
-ignore_min_size,
-ignore_aspect,
-ignore_resizeinc,
+ignore_max_size,
+ignore_min_size,
+ignore_aspect,
+ignore_resizeinc,
may be used to override application-supplied size hints. The four
first ones are tables with the fields w and h, indicating
the width and height size hints in pixels, and the latter ignore
@@ -1098,7 +1126,7 @@ winprop is a boolean.
Finally, the boolean
-userpos option may be used to
+userpos option may be used to
override the USPosition flag of the size hints. Normally,
when this flag is set, Ion tries to respect the supplied window
position more than when it is not set. Obviously, this makes sense
@@ -1113,15 +1141,22 @@ only for floating windows.
-The identification information in the winprop specification is usually the
-class,
-role,
-instance and
-name
-of the window. The name field is a Lua-style regular expression
-matched against the window's title and the rest are strings that must
-exactly match the corresponding window information. It is not necessary
-to specify all of these fields.
+The identification information supported are
+class,
+role,
+instance,
+name,
+is_transient, and
+is_dockapp.
+It is not necessary to specify all of these fields.
+The first three are strings, and must exactly match the
+corresponding information obtained from the window's properties.
+The name field is a Lua-style regular expression matched against
+the window's title. The is_transient field is a boolean that can
+be used to include or exclude transients only, while the is_dockapp
+field is set by Ion for the dock windows of Window Maker dockapp protocol
+dockapps. Usually this is the only information available for these
+icon windows.
Ion looks for a matching winprop in the order listed by the following
@@ -1138,7 +1173,7 @@ fields) is tried.
| class |
role |
instance |
-name |
+other |
| E |
E |
@@ -1184,8 +1219,9 @@ fields) is tried.
-If there are multiple winprops with other identification information
-the same but different name, the longest match is chosen.
+If there are multiple matching winprops with the same
+class, role and instance, but other information
+different, the most recently defined one is used.
@@ -1199,7 +1235,7 @@ can be used to list the identification information required to set winprops
for a window and all the transient windows managed within it.
-
+
Another way to get the identification information is to use xprop.
Simply run To get class and instance, simply run xprop WM_CLASS
and click on the particular window of interest. The class is the latter of
@@ -1208,21 +1244,24 @@ windows have this property - use the command xprop WM_ROLE.
This method, however, will not work on transients.
-
-So-called ''transient windows'' are usually short-lived dialogs (although
+
+So-called ``transient windows'' are usually short-lived dialogs (although
some programs abuse this property) that have a parent window that they are
-''transient for''. On tiled workspaces Ion displays these windows
-simulatenously with the parent window at the bottom of the same frame.
+``transient for''. On tiled workspaces Ion displays these windows
+simultaneously with the parent window at the bottom of the same frame.
Unfortunately xprop is stupid and can't cope with this situation,
returning the parent window's properties when the transient is clicked on.
For this reason you'll have to do a little extra work to get the properties
-for that window.3.4
+for that window.3.3
Finally, it should be mentioned that too many authors these days
-''forget'' to set this vital identification to anything meaningful:
-everything except name is the same for all of the programs's
-windows, for example.
+``forget'' to set this vital identification to anything meaningful:
+everything except name is the same for all of the program's
+windows, for example. Some other programs only set this information
+after the window has been mapped, i.e. the window manager has been
+told to start managing it, which is obviously too late.
+Gtk applications in particular are often guilty on both counts.
@@ -1251,36 +1290,7 @@ defwinprop{
-
-
-Mozilla Firebird (0.7) incorrectly does not set the WM_TRANSIENT_FOR
-property for the dialog that is used to ask the action to take for a file.
-It, however, sets the the property point to the main window for the save
-dialog. This can be annoying and confusing, as the first dialog is not
-closed before the second is displayed.
-
-
-We'd like the first dialog to be transient to the main window. The closest
-we can get to that is to consider it transient to the current window (if
-there's one). Unfortunately Firebird does not set any meaningful classes,
-instances or roles for the windows, so we'll have to rely on an ugly title
-match.
-
-
-
-defwinprop{
- class = "MozillaFirebird-bin",
- name = "Opening .*",
- transient_mode = "current",
-}
-
-
-
-
-
@@ -1297,7 +1307,7 @@ defwinprop{
For this example to work, we have to somehow create a frame named
-sysmonframe. One way to do this is to make the following
+`sysmonframe'. One way to do this is to make the following
call in the Mod1+F3 Lua code query:
@@ -1309,35 +1319,192 @@ mod_query.query_renameframe(_)
Recall that _ points to the multiplexer (frame or screen) in which
the query was opened. Running this code should open a new query prefilled
with the current name of the frame. In our example we would change the
-name to sysmonframe, but we could just as well have used the
+name to `sysmonframe', but we could just as well have used the
default name formed from the frame's class name and an instance number.
+
+
+
+3.6 The statusbar
+
+
+
+The mod_statusbar module provides a statusbar that adapts to
+layouts of tilings, using only the minimal space needed. Ion only
+supports one adaptive ``status display'' object per screen, so this
+statusbar is mutually exclusive with the embedded mode of mod_dock
+docks.
+
+
+The statusbar is configured in cfg_statusbar.lua. Typically,
+the configuration consists of two steps: creating a statusbar with
+mod_statusbar.create, and then launching the separate
+ion-statusd status daemon process with
+mod_statusbar.launch_statusd. This latter phase is done
+automatically, if it was not done by the configuration file, but
+the configuration file may pass extra parameters to ion-statusd
+monitors. (See Section 5.4 for more information on
+writing ion-statusd monitors.)
+
+
+A typical cfg_statusbar.lua configuration might look as follows:
+
+
+
+-- Create a statusbar
+mod_statusbar.create{
+ screen = 0, -- First screen,
+ pos = 'bl', -- bottom left corner
+ systray = true, -- Swallow systray windows
+
+ -- The template
+ template = "[ %date || load:% %>load || mail:% %>mail_new/%>mail_total ]"
+ .. " %filler%systray",
+}
+
+-- Launch ion-statusd.
+mod_statusbar.launch_statusd{
+ -- Date meter
+ date={
+ -- ISO-8601 date format with additional abbreviated day name
+ date_format='%a %Y-%m-%d %H:%M',
+ },
+}
+
+
+
+
+
+
+
+The template specifies what is shown on the statusbar; for information
+on the other options to mod_statusbar.create, see the reference.
+Strings of the form `%spec' tokens specially interpreter by
+the statusbar; the rest appears verbatim. The spec typically
+consists of the name of the value/meter to display (beginning with a latin
+alphabet), but may be preceded by an alignment specifier and a number
+specifying the minimum width. The alignment specifiers are: `>'
+for right, `<' for left, and `|' for centring. Additionally,
+space following `%' (that is, the string `% '), adds
+``stretchable space'' at that point. The special string `%filler'
+may be used to flush the rest of the template to the right end of
+the statusbar.
+
+
+The stretchable space works as follows: mod_statusbar remembers
+the widest string (in terms of graphical presentation) that it has
+seen for each meter, unless the width has been otherwise constrained.
+If there is stretchable space in the template, it tries to make the
+meter always take this much space, by stretching any space found in
+the direction indicated by the alignment specifier: the opposite
+direction for left or right alignment, and both for centring.
+
+
+
+
+
+
+The special `%systray' and `%systray_*'
+(`*' varying) monitors indicate where to place system tray
+windows. There may be multiple of these. KDE-protocol system tray
+icons are placed in `%systray' automatically, unless disabled
+with the systray option. Otherwise the statusbar winprop may
+be used to place any window in any particular `%systray_*'.
+
+
+
+
+
+
+The part before the first
+underscore of each monitor name, describes the script/plugin/module
+that provides the meter, and any configuration should be passed
+in the a corresponding sub-table mod_statusbar.launch_statusd.
+Ion comes with date, load and mail (for plain old mbox)
+ion-statusd monitor scripts. More may be obtained from
+the scripts repository [1]. These included scripts
+provide the following monitors and their options
+
+
+
+
+
+
+Options: date_format: The date format in as seen above,
+in the usual strftime format. formats: table of
+formats for additional date monitors, the key being the name
+of the monitor (without the `date_' prefix).
+
+
+Monitors: `date' and other user-specified ones with the
+`date_' prefix.
+
+
+
+
+
+
+Options: update_interval: Update interval in milliseconds
+(default 10s). important_threshold: Threshold above which
+the load is marked as important (default 1.5), so that the
+drawing engine may be suitably hinted. critical_threshold:
+Threshold above which the load is marked as critical (default 4.0).
+
+
+Monitors: `load' (for all three values),
+`load_1min', `load_5min' and `load_15min'.
+
+
+
+
+
+
+Options: update_interval: Update interval in milliseconds
+(default 1min). mbox: mbox-format mailbox location
+(default $MAIL).
+files: list of additional mailboxes, the key giving the
+name of the monitor.
+
+
+Monitors: `mail_new', `mail_unread',
+`mail_total', and corresponding
+`mail_*_new', `mail_*_unread', and `mail_*_total'
+for the additional mailboxes (`*' varying).
+
+
+
Footnotes
-- ...keysymdef.h...keysymdef.h3.1
- This file can usually be found in the directory
/usr/X11R6/include/X11/.
-- ... such... such3.2
- Completely useless keys that should be
gotten rid of in the author's opinion.
-- ... handling.... window.3.3
-- See the wcirculate.lua script in the Ion
- scripts repository http://iki.fi/tuomov/repos/ion-scripts-3/.
-
-
-- ... window.3.4
- There's a patch to xprop to
fix this, but nothing seems to be happening with respect to including it in
XFree86.
@@ -1346,31 +1513,31 @@ XFree86.
-
-
-
-
