Ion3, to which document applies, stores its stock configuration files in
<SPAN CLASS="textit">/usr/local/etc/ion3/</SPAN> unless you, the OS package maintainer or
whoever installed the package on the system has modified the variables
-<TT>PREFIX</TT><A NAME="585"></A> or
-<TT>ETCDIR</TT><A NAME="586"></A> in
-<SPAN CLASS="textit">system.mk</SPAN><A NAME="587"></A> before compiling Ion.
+<TT>PREFIX</TT><A NAME="584"></A> or
+<TT>ETCDIR</TT><A NAME="585"></A> in
+<SPAN CLASS="textit">system.mk</SPAN><A NAME="586"></A> 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.
As seen above, the functions that create key binding specifications require
a <TT>keyspec</TT> argument. This argument should be a string containing the
name of a key as listed in the X header file <SPAN CLASS="textit">keysymdef.h</SPAN><A NAME="tex2html7"
- HREF="#foot858"><SUP><SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">1</SPAN></SUP></A> without the <TT>XK_</TT> prefix.
-<A NAME="859"></A>
+ HREF="#foot857"><SUP><SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">1</SPAN></SUP></A> without the <TT>XK_</TT> prefix.
+<A NAME="858"></A>
Most of the key names are quite intuitive while some are not. For example,
the <SPAN CLASS="textbf">Enter</SPAN> key on the main part of the keyboard has the less common
name <SPAN CLASS="textbf">Return</SPAN> while the one the numpad is called <SPAN CLASS="textbf">KP_Enter</SPAN>.
<BLOCKQUOTE>
<SPAN CLASS="textbf">Shift</SPAN>, <SPAN CLASS="textbf">Control</SPAN>, <SPAN CLASS="textbf">Mod1</SPAN> to <SPAN CLASS="textbf">Mod5</SPAN>,
<SPAN CLASS="textbf">AnyModifier</SPAN> and <SPAN CLASS="textbf">Lock</SPAN>.
+<A NAME="859"></A>
<A NAME="860"></A>
<A NAME="861"></A>
<A NAME="862"></A>
<A NAME="863"></A>
-<A NAME="864"></A>
</BLOCKQUOTE>
<P>
X allows binding all of these modifiers to almost any key and while this
list of modifiers does not explicitly list keys such as
-<SPAN CLASS="textbf">Alt</SPAN><A NAME="865"></A> that are common on modern keyboards, such
+<SPAN CLASS="textbf">Alt</SPAN><A NAME="864"></A> that are common on modern keyboards, such
keys are bound to one of the <SPAN CLASS="textbf">ModN</SPAN>. On systems running XFree86
<SPAN CLASS="textbf">Alt</SPAN> is usually <SPAN CLASS="textbf">Mod1</SPAN>. On Suns <SPAN CLASS="textbf">Mod1</SPAN> is the diamond key
and <SPAN CLASS="textbf">Alt</SPAN> something else. One of the ''flying window'' keys on so
called Windows-keyboards is probably mapped to <SPAN CLASS="textbf">Mod3</SPAN> if you have
-such a key. Use the program <SPAN CLASS="textit">xmodmap</SPAN><A NAME="866"></A>
+such a key. Use the program <SPAN CLASS="textit">xmodmap</SPAN><A NAME="865"></A>
to find out what exactly is bound where.
<P>
<P>
Ion ignores the <SPAN CLASS="textbf">Lock</SPAN> modifier and any <SPAN CLASS="textbf">ModN</SPAN> (<SPAN CLASS="MATH"></SPAN>)
-bound to <SPAN CLASS="textbf">NumLock</SPAN><A NAME="867"></A> or
-<SPAN CLASS="textbf">ScrollLock</SPAN><A NAME="868"></A>
+bound to <SPAN CLASS="textbf">NumLock</SPAN><A NAME="866"></A> or
+<SPAN CLASS="textbf">ScrollLock</SPAN><A NAME="867"></A>
by default because such<A NAME="tex2html8"
- HREF="#foot837"><SUP><SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">2</SPAN></SUP></A> locking keys may otherwise
+ HREF="#foot836"><SUP><SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">2</SPAN></SUP></A> locking keys may otherwise
cause confusion.
<P>
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 <SPAN CLASS="textbf">Button1</SPAN> to
-<SPAN CLASS="textbf">Button5</SPAN><A NAME="869"></A>. Additionally the
+<SPAN CLASS="textbf">Button5</SPAN><A NAME="868"></A>. 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
</H3>
<P>
-<A NAME="1115"></A>
-<A NAME="1170"></A>
+<A NAME="1114"></A>
<A NAME="1171"></A>
<A NAME="1172"></A>
+<A NAME="1173"></A>
In the stock configuration file setup, menus are defined in the file
<SPAN CLASS="textit">cfg_menus.lua</SPAN> as previously mentioned. The <SPAN CLASS="textit">mod_menu</SPAN> module
must be loaded for one to be able to define menus, and this is done with
<TR><TD ALIGN="LEFT"><TT>workspacelist</TT></TD>
<TD ALIGN="LEFT">List of all workspaces. Activating an entry jumps to that workspaces.</TD>
</TR>
+<TR><TD ALIGN="LEFT"><TT>focuslist</TT></TD>
+<TD ALIGN="LEFT">List of client windows with recent activity in them, followed by
+ previously focused client windows.</TD>
+</TR>
+<TR><TD ALIGN="LEFT"><TT>focuslist_</TT></TD>
+<TD ALIGN="LEFT">List of previously focused client windows.</TD>
+</TR>
<TR><TD ALIGN="LEFT"><TT>stylemenu</TT></TD>
<TD ALIGN="LEFT">List of available <SPAN CLASS="textit">look_*.lua</SPAN> style files. Activating an entry
loads that style and ask to save the selection.</TD>
after which the selected entry is activated. This function is meant to
be used for implementing, for example, Win***s-style <SPAN CLASS="textbf">Alt-Tab</SPAN>
handling.<A NAME="tex2html9"
- HREF="#foot1173"><SUP><SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">3</SPAN></SUP></A></TD>
+ HREF="#foot1174"><SUP><SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">3</SPAN></SUP></A></TD>
</TR>
</TABLE>
</H2>
<P>
-The so-called ''winprops''<A NAME="1266"></A> can be used to change how
+The so-called ''winprops''<A NAME="1269"></A> 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
<TT>defwinprop</TT> with a table containing the properties to set and the
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1410"></A>
+<DD><A NAME="1429"></A>
Set this to <TT>true</TT> 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
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1411"></A>
+<DD><A NAME="1430"></A>
The table should contain the entries <TT>w</TT> and <TT>h</TT> that
override application-supplied aspect ratio hint.
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1412"></A>
+<DD><A NAME="1431"></A>
Set this to open the window in a floating frame, when
in a group.
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1413"></A>
+<DD><A NAME="1432"></A>
Should the window be initially in full screen mode?
</DD>
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1414"></A>
+<DD><A NAME="1433"></A>
Should configure requests on the window be ignored?
Only has effect on floating windows.
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1415"></A>
+<DD><A NAME="1434"></A>
Ignore extended WM hints <TT>_NET_ACTIVE_WINDOW</TT> request.
</DD>
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1416"></A>
+<DD><A NAME="1435"></A>
Should application supplied size increments be ignored?
</DD>
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1417"></A>
+<DD><A NAME="1436"></A>
Should a newly created client window always be made
active, even if the allocated frame isn't.
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1418"></A>
+<DD><A NAME="1437"></A>
The table should contain the entries <TT>w</TT> and <TT>h</TT> that
override application-supplied maximum size hint.
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1419"></A>
+<DD><A NAME="1438"></A>
Similar to <TT>max_size</TT> but for the minimum size hint.
</DD>
</DL>
+<P>
+
+ <DL>
+<DT><STRONG>Winprop:</STRONG></DT>
+<DD><TT>new_group</TT> (string)
+
+</DD>
+<DT><STRONG>Description:</STRONG></DT>
+<DD><A NAME="1439"></A>
+ If the region specified by <TT>target</TT> winprop does not exist
+ (or that winprop is not set), create a new workspace using the
+ previously stored layout (see <A HREF="node7.html#fn:ioncore.deflayout"><TT>ioncore.deflayout</TT></A>) named by
+ this property. After creating the workspace, <TT>target</TT> is
+ attempted to be found again. (If that still fails, the newly
+ created workspace is still asked to manage the client window.)
+
+</DD>
+</DL>
+
<P>
<DL>
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1420"></A>
+<DD><A NAME="1440"></A>
Discard this winprop after first use.
</DD>
</DL>
+<P>
+
+ <DL>
+<DT><STRONG>Winprop:</STRONG></DT>
+<DD><TT>statusbar</TT> (string)
+
+</DD>
+<DT><STRONG>Description:</STRONG></DT>
+<DD><A NAME="1441"></A>
+ Put the window on the statusbar, in the named tray component,
+ (The default tray component is called simply ``<TT>systray</TT>'',
+ and others you give names to in your custom template, always
+ prefixed by ``<TT>systray_</TT>''.
+
+</DD>
+</DL>
+
<P>
<DL>
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1421"></A>
+<DD><A NAME="1442"></A>
Should a newly mapped client window be switched to within
its frame.
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1422"></A>
+<DD><A NAME="1443"></A>
The name of an object (workspace, frame) that should manage
- windows of this type.
+ windows of this type. See also <TT>new_group</TT>.
</DD>
</DL>
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1423"></A>
+<DD><A NAME="1444"></A>
"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
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1424"></A>
+<DD><A NAME="1445"></A>
When transients are managed by the client window itself (as it
is the case on tiled workspaces), should the transients be
placed at the top of the window instead of bottom?
</DD>
<DT><STRONG>Description:</STRONG></DT>
-<DD><A NAME="1425"></A>
+<DD><A NAME="1446"></A>
Should frames be made transparent when this window is selected?
<BR>
<P>
The identification information in the winprop specification is usually the
-<TT>class</TT><A NAME="1426"></A>,
-<TT>role</TT><A NAME="1427"></A>,
-<TT>instance</TT><A NAME="1428"></A> and
+<TT>class</TT><A NAME="1447"></A>,
+<TT>role</TT><A NAME="1448"></A>,
+<TT>instance</TT><A NAME="1449"></A> and
<TT>name</TT>
of the window. The <TT>name</TT> field is a Lua-style regular expression
matched against the window's title and the rest are strings that must
for a window and all the transient windows managed within it.
<P>
-<A NAME="1383"></A>
+<A NAME="1402"></A>
Another way to get the identification information is to use <TT>xprop</TT>.
Simply run To get class and instance, simply run <TT>xprop WM_CLASS</TT>
and click on the particular window of interest. The class is the latter of
This method, however, will not work on transients.
<P>
-<A NAME="1387"></A>
+<A NAME="1406"></A>
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
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.<A NAME="tex2html11"
- HREF="#foot1430"><SUP><SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">4</SPAN></SUP></A>
+ HREF="#foot1451"><SUP><SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">4</SPAN></SUP></A>
<P>
Finally, it should be mentioned that too many authors these days
''forget'' to set this vital identification to anything meaningful:
<P>
<BR><HR><H4>Footnotes</H4>
<DL>
-<DT><A NAME="foot85
8">...keysymdef.h</A><A
+<DT><A NAME="foot85
7">...keysymdef.h</A><A
HREF="node4.html#tex2html7"><SUP><SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">1</SPAN></SUP></A></DT>
<DD>This file can usually be found in the directory
<SPAN CLASS="textit">/usr/X11R6/include/X11/</SPAN>.
</DD>
-<DT><A NAME="foot83
7">... such</A><A
+<DT><A NAME="foot83
6">... such</A><A
HREF="node4.html#tex2html8"><SUP><SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">2</SPAN></SUP></A></DT>
<DD>Completely useless keys that should be
gotten rid of in the author's opinion.
</DD>
-<DT><A NAME="foot117
3">... handling.</A><A
+<DT><A NAME="foot117
4">... handling.</A><A
HREF="node4.html#tex2html9"><SUP><SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">3</SPAN></SUP></A></DT>
<DD>See the <SPAN CLASS="textit">wcirculate.lua</SPAN> script in the Ion
scripts repository <TT><A NAME="tex2html10"
HREF="http://iki.fi/tuomov/repos/ion-scripts-3/">http://iki.fi/tuomov/repos/ion-scripts-3/</A></TT>.
</DD>
-<DT><A NAME="foot14
30">... window.</A><A
+<DT><A NAME="foot14
51">... window.</A><A
HREF="node4.html#tex2html11"><SUP><SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">4</SPAN></SUP></A></DT>
<DD>There's a patch to <TT>xprop</TT> to
fix this, but nothing seems to be happening with respect to including it in
projects / ion3-doc.git / blobdiff