\section{Winprops}
\label{sec:winprops}
-The so-called ''winprops''\index{Winprops} can be used to change how
+The so-called ``winprops''\index{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
\code{defwinprop} with a table containing the properties to set and the
\begin{winprop}{statusbar}{string}
\index{statusbar@\var{statusbar}}
Put the window in the statusbar, in the named tray component,
- (The default tray component is called simply \code{"systray"},
+ (The default tray component is called simply \codestr{systray},
and others you give names to in your custom template, always
- prefixed by \code{"systray_"}.
+ prefixed by \codestr{systray\_}.
\end{winprop}
\begin{winprop}{transient_mode}{string}
\index{transient-mode@\var{transient_mode}}
- \code{"normal"}: No change in behaviour. \code{"current"}:
+ \codestr{normal}: No change in behaviour. \codestr{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. \code{"off"}: The window should
+ transient by the application. \codestr{off}: The window should
be handled as a normal window even if it is marked as a
transient by the application.
\end{winprop}
\subsection{Classes, roles and instances}
\label{sec:classesrolesinstances}
-The identification information in the winprop specification is usually the
+The identification information supported are
\var{class}\index{class@\var{class}!winprop},
\var{role}\index{role@\var{role}!winprop},
-\var{instance}\index{instance@\var{instance}!winprop} and
-\var{name}
-of the window. The \var{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.
+\var{instance}\index{instance@\var{instance}!winprop},
+\var{name}\index{name@\var{name}!winprop},
+\var{is_transient}\index{is-transient@\var{is_transient}!winprop}, and
+\var{is_dockapp}\index{is-dockapp@\var{is_dockapp}!winprop}.
+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 \var{name} field is a Lua-style regular expression matched against
+the window's title. The \var{is_transient} field is a boolean that can
+be used to include or exclude transients only, while the \var{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
+\emph{icon} windows.
Ion looks for a matching winprop in the order listed by the following
table. An 'E' indicates that the field must be set in the winprop
\begin{center}
\begin{tabular}{llll}
- \tabhead{\var{class} & \var{role} & \var{instance} & \var{name}}
+ \tabhead{\var{class} & \var{role} & \var{instance} & other}
E & E & E & E \\
E & E & E & * \\
E & E & * & E \\
\end{tabular}
\end{center}
-If there are multiple winprops with other identification information
-the same but different \var{name}, the longest match is chosen.
+If there are multiple matching winprops with the same
+\var{class}, \var{role} and \var{instance}, but other information
+different, the most recently defined one is used.
+
\subsection{Finding window identification}
This method, however, will not work on transients.
\index{transient}
-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 \command{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
XFree86.}
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.
+
\subsection{Some common examples}
}
\end{verbatim}
-\subsubsection{Fixing a Mozilla Firebird transient}
-
-Mozilla Firebird (0.7) incorrectly does not set the \code{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.
-
-\begin{verbatim}
-defwinprop{
- class = "MozillaFirebird-bin",
- name = "Opening .*",
- transient_mode = "current",
-}
-\end{verbatim}
-
\subsubsection{Forcing newly created windows in named frames}
The following winprop should place xterm started with command-line parameter
\end{verbatim}
For this example to work, we have to somehow create a frame named
-\code{sysmonframe}. One way to do this is to make the following
+\codestr{sysmonframe}. One way to do this is to make the following
call in the \key{Mod1+F3} Lua code query:
\begin{verbatim}
Recall that \code{_} 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 \code{sysmonframe}, but we could just as well have used the
+name to \codestr{sysmonframe}, but we could just as well have used the
default name formed from the frame's class name and an instance number.
projects / ion3.git / blobdiff