Please read the sample.fvwm-ewmh file and update your FVWM configuration. This file is installed in the FVWM data directory, usually prefix/share/fvwm/ where prefix is the FVWM installation prefix (typically /usr or /usr/local). You can also find this file in the fvwm-ewmh source and at the fvwm-ewmh web page: http://fvwm-ewmh.sourceforge.net.
Basically you should do the following changes to your configuration:
* Add "Module FvwmNetHints" to your FVWM start functions. Configure
FvwmNetHints. In a perfect world, the default configuration will work fine.
However, some workarounds are needed to fix some focus problems.
* Enable the UseListSkip fvwm-ewmh FvwmPager option.
* Setup some FVWM styles for certain compliant applications (as kdesktop
and kicker). Again, these are workarounds.
* If you use a desktop application as kdesktop or Nautilus desktop you
should disable most of your Root Mouse bindings (by using
the .fnh-desktop-start file).
* Take care that there are no interactions between FVWM key bindings and
some special key bindings used by some special applications as kdesktop and
kicker.
* Replace the FVWM Maximize builtin function by the FvwmNetHints one
(by using the .fnh-start file).
* Use the session exit function if you use a session manager
(as ksmserver).
You MUST really update your configuration following sample.fvwm-ewmh especially if you use a Desktop application (as kdesktop or Nautilus desktop). Also, this sample contains a few important workaround.
One thing that you should be award is that Key and Mouse bindings work in a special way on Desktop window: the context for bindings under such window is R (root) and not W (window), and the associated action is also executed under the root context. Moreover, this type of application needs mouse bindings and you should give to it some of your root mouse bindings, e.g. add the following to the .fnh-desktop-start configuration file (which should be located in your $FVWM_USERDIR directory):
Mouse 1 R N Mouse 1 R S Mouse 1 R C Mouse 2 R A Mouse 3 R A
if you use kdesktop or Nautilus desktop. See the START/STOP CONFIGURATION FILES section for more details on the .fnh-desktop-start file.
Finally, some tricks for running FVWM with KDE version 2 and FvwmNetHints are given at the fvwm-ewmh web page.
The Extended Window Manager Hints, EWMH for short, defines interactions between window managers, applications and the utilities that form part of a desktop environment. It builds on the ICCCM, which defines wm/client interactions at a lower level. It was born out of a need to replace the original Gnome WM specification, although this specification has been designed to be independent of any one desktop environment. (this is paragraph is from the EWMH specification http://www.freedesktop.org/standards/wm-spec.html).
This specification is implemented in KDE version >= 2 and in GNOME version 2. FvwmNetHints allows FVWM to work fine with applications which implement this specification. In this man page an application which respect this spec. is called a compliant applications.
Applications are not equal with respect to the EWMH. Basically a classical or normal compliant application should work fine with any window manager (however, even such an application can take advantage of the spec. and the ability to provide a mini icon can be please). On the other hand, some special applications as a compliant pager or task bar should work with a compliant window manager because they have to speak with the window manager (activate this window, close this one, which applications I have to represent, I want to be on all desktop, put this window on all desktop ...etc). So there are "Normal" applications, "ToolBar" applications (pager, task bar), "Dock" applications (dock or panel witch display various goodies and can contain a ToolBar), "Menu" windows (pinnable menus), "Dialog" windows (kind of transient window). Also, unfortunately, there are "Desktop" applications which are kind of file manager root window and which cause problems with a window manager which has not be written with this application in head (I do not know why this kind of application are so popular), anyway FvwmNetHints try to support this kind of application.
An other thing that the user should know is the concept of "Working Area".
When you run FVWM
without FvwmNetHints the Working Area is your full visible screen.
However, a compliant application as a Dock can ask to reserve space at the
edge of the screen. Then, the Working Area is your full visible screen minus
these reserved space.
For example FvwmNetHints take in account the Working Area in its Maximize
command to be able to not cover space reserved by some applications.
FvwmNetHints gets its configuration from fvwm2: fvwm2 send to FvwmNetHints its configuration lines which begin by *FvwmNetHints. Also, at startup FvwmNetHints ask fvwm2 to read the file .fnh-start (in your $FVWM_USERDIR directory) if it exists. This file is not for the FvwmNetHints configuration options as well as others special FvwmNetHints configuration files: .fnh-stop, .fnh-desktop-start, .fnh-desktop-stop and .fnh-pconfig. See the START/STOP CONFIGURATION FILES section and the PERSISTENT CONFIGURATION FILE section for information on these files. This module is more or less dynamic: FvwmNetHints take in account the changes you made in its configuration when running (e.g., by using the fvwm2 Read command or FvwmConsole). However, some of the configuration options are only partially dynamic in the sense that the change will be applied only to windows which will be started after the change. Moreover, FvwmNetHints support a few commands (see the COMMANDS section). Finally, the "FvwmNetHints Styles" configuration options are described in the next section.
.".TP .".BI "*FvwmNetHints: Charset " charset ."Where .".I charset ."is a charset as given by the command "iconv --list" or "locale -m". ."This option is used by the previous option. However, if your machine ."is well configured you do not need to use this command as the charset ."is automatically detected (via the LC_CTYPE environment variable).
*FvwmNetHints: NoIconAction SendToModule FvwmAnimate animate
(this can cause strange result due to a bug in the EWMH specifications). A blank or null action turns this feature off.
This section describes the commands of the form
*FvwmNetHints: XYXNetStyle styles
Where XYZ is either Desktop, Dock, ToolBar, Menu, Dialog or Modal and
where styles is a comma separated list containing one or more of the
keywords:
Slippery / Sticky, CirculateHit / CirculateSkip,
WindowListHit / WindowListSkip, Focus / NoFocus,
Title / NoTitle, Border / NoBorder,
DecorationOverride / NoOverride, Layer l
where
l
is an integer > -2.
These styles are applied to compliant application of the corresponding XYZ
type (note that Modal is not a type but a state). These options are
totally dynamic.
Slippery, Sticky, CirculateHit, CirculateSkip, WindowListHit, WindowListSkip, Title, NoTitle have basically the same signification than the corresponding fvwm2 Style options. Border (respectively, NoBorder) allows (respectively, forbid) fvwm2 to draw a border around the application. Focus (respectively, NoFocus) allows (respectively, forbid) fvwm2 to give the focus to an application. FvwmNetHints respects the (MWM) decorations hints given by a compliant applications and do not applies the Title / NoTitle, Border / NoBorder options to applications which provides such hints (this is in the EWMH spec.). The DecorationOverride option cause FvwmNetHints to apply the Title / NoTitle, Border / NoBorder options even with such compliant applications (Use this option if you know what you do). NoOverride disables this behavior. Layer l set the layer of the application to layer l if l is > 0, if l is 0 or -1 the layer will be not changed by FvwmNetHints.
The FvwmNetHints styles are not of the same nature as the fvwm2 styles. First of all, there are more strong, e.g., if a compliant application has the WindowListSkip FvwmNetHints style and you type Style name_of_the_app WindowListHit then this will not work! Also the Title and Border FvwmNetHints styles does not ask to fvwm2 to put a border on/around a window but allows fvwm2 to do it or not (with the Title , NoTitle, BorderWidth, HandleWidth fvwm2 styles). On the other hands the NoTitle and NoBorder FvwmNetHints styles will forbid such decorations (except if the applications really want a border or a title and you do not use the DecorationOverride FvwmNetHints style). However, the NoDecorHint fvwm2 style can break this (but only temporary I think): you should not use Style name NoDecorHint with a name which match a compliant (not normal) applications (anyway, any reasonable FVWM configuration file should contains the line Style * MwmDecor and use the NoDecorHint fvwm2 style for broken applications only). The same remarks apply for the Focus / NoFocus FvwmNetHints styles (here the Lenience fvwm2 style can "break" the things).
More technically, the EWMH spec. defines a new window manager protocol (the _NET_PING protocol): a Window Manager (FvwmNetHints in our case) can send to an application which supports this protocol a "Ping" message, then the application must answer immediately. This allows the window manager to determine if the application is still processing X events and this can be used by the Window Manager to determine if an application which fails to close has stopped responding (i.e., is dead), or has stalled for some other (good) reason, such as waiting for user confirmation.
Let us now describe the FvwmNetHints Ping command. If action is Info then some information on the window are printed to stderr, as the window type and the pid (if supplied by a NET hint). Moreover, if this window support the ping protocol a ping message is send to this application with an identifier. Then, FvwmNetHints report the answer or the non answer of the application accordingly to time-out which is the time (in sec) we wait for an answer. If action is Delete, Close or Destroy then first of all the corresponding fvwm2 command is executed. Then, with Delete (respectively, Close) if the window support the Ping protocol a ping message is send and if the window does not answer to this message or does not remove itself before time-out seconds, a SIGTERM (respectively, a SIGKILL) signal is send to the application. With Destroy if we can get the PID of the application (with a NET hint), then in any case a SIGKILL signal is send to the application after time-out seconds. Finally, if action is PingTerm (respectively, PingKill), then if the window support the Ping protocol a ping message is send and if the window does not answer to this message before time-out second, a SIGTERM (respectively, a SIGKILL) signal is send to the application.
The only applications I know which support the Ping protocol are applications build with GTK+-2.x (as GNOME 2 applications). KDE does not support the Ping protocol, but we can found the PID of an application with a NET hints (this is used in the Destroy command).
When FvwmNetHints is started (respectively, a Desktop application is detected), then FvwmNetHints ask fvwm2 to read (if it exists) a file called .fnh-start (respectively, .fnh-desktop-start) in the $FVWM_USERDIR directory. If the Desktop application is deleted, then fvwm2 will read .fnh-desktop-stop in the $FVWM_USERDIR directory. Moreover, if FvwmNetHints is stoped with the SendToModule FvwmNetHints Quit command, then fvwm2 will read .fnh-stop and .fnh-desktop-stop if a Desktop application was detected.
The .fnh-start file allows to have a different FVWM configuration
whether you run or not FvwmNetHints. Typically, you can in this
file redefine some bindings, window operations menu or/and functions
for using the FvwmNetHints maximize command and the FvwmNetHints Delete,
Close and Destroy commands (via the Ping command) in the place of the
corresponding fvwm2 commands. If you want to be able to quit FvwmNetHints
during a session you can use the .fnh-stop file for restoring the fvwm2 commands.
The .fnh-desktop-start file is useful only if you use only sometimes a
Desktop application.
Typically, you can put in this file the unbinding described in the
USAGE
section and you may rebind your Mouse Root bindings (by adding, say, the
M (Alt) modifier). Then, in .fnh-desktop-stop you can redefine your
original Mouse Root bindings (useful if you want to delete the Desktop
application during a session).
Moreover, you can use the following configurations option to add files to be read (useful for a system administrator or configuration system as fvwm-themes).
FvwmNetHints use a special configuration file for some parameters that can be changed by an "external" compliant application and that the user may want to be persistent. A priori, the user does not need to edit this file: it is updated by FvwmNetHints itself. However, this is not forbidden and you must edit it to define your desktop names if you do not want to use a compliant GUI (as kcontrol) to do so. But you must use the ReloadPConfig command after you have edited this file (see the COMMANDS section). The name of this file is ".fnh-pconfig" and can be found in your $FVWM_USERDIR directory (~/.fvwm by default). In this file only the lines which begin by one of the configuration option below are taken in account.
Olivier Chapuis <olivier.chapuis@free.fr>
This module is distributed by the same terms as FVWM itself. See GNU General Public License for details.
|
|
|
|