Extended Window Manager Hints Support For FVWM

Welcome to fvwm-ewmh!

fvwm-ewmh is made up of a module, FvwmNetHints, and a patch against the last stable FVWM source tree (fvwm-2.4.8). With these, FVWM can handle Extended Window Manager Hints from the freedesktop group. This allows, for example, running FVWM with KDE version >=2 and GNOME version 2.

Please report bugs to olivier.chapuis@free.fr. Patches against the English of the web pages and the manual page welcome!

Note: The current development version of FVWM (the 2.5 series) has native EWMH support. For technical reason I choose to do not use a module to accomplish this ewmh support. So configuration is totally different and you should update your configuration file if you upgrade from fvwm-2.4.x + fvwm-ewmh to fvwm-2.5.x (see the fvwm man page and search for EWMH). Also, the fvwm 2.5 series has a number of new feature as side title, PNG support, anti-aliased font rendering, better internationalization and much more. However, the fvwm 2.5 versions are development versions and we cannot warranty the same level of stability than for the 2.4 versions.

Table Of Contents


From the EWMH specification:
This specification is implemented in KDE version >=2 and GNOME version 2. FvwmNetHints allows FVWM to work fine with applications which implement this specification. (this paragraph is from the FvwmNetHints manual page where it is continued).



This section describe the installation procedure from the source. If you use the binary rpm package, just use rpm as usual (but it is maybe preferable to rpm -e any installed version of FVWM).

First of all you need the FVWM source: fvwm-2.4.8.tar.gz or fvwm-2.4.8.tar.bz2. In addition of the usual libraries and headers needed for a normal FVWM installation, so that fvwm-ewmh be fully functional, you need the XPM library and headers (only optional for fvwm-2.4.8 but strongly recommended) and either the Imlib library and headers (only optional for fvwm-2.4.8 for FvwmGtk) or the Imlib2 library and headers. You should do the following:

If you get a problem, try first to compile FVWM without fvwm-ewmh. If this work fine, please send me a bug report.


There is a manual page: man FvwmNetHints and a configuration sample. For new or unexperimented FVWM users I recommend the use of FVWM Themes. Since FVWM Themes version 0.6.0 FVWM Themes has an integrated support for fvwm-ewmh and the things should work out of the box: take a look at the Running with FVWM Themes section.
The sample configuration has been written with FVWM Themes (version < 0.6.0) configuration scheme in head.

You MUST be award of a few things specially if you use a desktop application (as kdesktop). Basically you should do the following changes to your configuration: All these are explained with a lot of details in the sample. REALLY, YOU SHOULD READ IT.


When you use KDE version >=2, a script called startkde is used for starting KDE and the K window manager kwin. To start FVWM with KDE you should replace the line which start your graphical environment (which can be found, in your .xsession, .Xclient or .xinitrc file) by a copy of this script and replace around the ead of this script "ksmserver --restore" by "ksmserver --restore --windowmanager fvwm2". If you use FVWM Themes you should add just before this line the line "fvwm-themes-start --session kde --no-start" and add a .fvwm2rc file in ~/.fvwm constituted by the line "Read themes-rc".

With KDE version >=2.1.1 (and maybe older version) the KDE applications which are started by ksmserver are those defined in ~/.kde/Autostart (typically user applications, this is well documented) and in $KDEDIR/share/autostart where kdesktop, kicker and other "central" KDE services are started (also, the LD_BIND_NOW variable set in startkde can come into play). I recommend that you copy the files you found in $KDEDIR/share/autostart/ in your own ~/.kde/share/autostart/ directory (create this directory). This way you override the system autostart dir and you can choose to do not start kdesktop (respectively, kicker) by removing kdesktop.desktop (respectively, panel.desktop). Note that you may have to remove a line of the form "X-KDE-autostart-after=kdesktop" in panel.desktop. But, the main point here is that to get a startup that look better you can edit kdesktop.desktop and panel.desktop to add the option --waitforwm to the lines "Exec=kdesktop" and "Exec=kicker" respectively. This option causes the application to wait that FvwmNetHints start. I do not know if there is a simpler method (or a user documented method) to realize the same tricks.


Here what you need in your .xsession, .Xclient or .xinitrc file:
export WINDOW_MANAGER="fvwm2"
gnome-session --choose-session=fvwm2

The argument to the --choose-session is just a key name: the name of the session when you save it. The first line defines the window manager executable. In fact the first line in only necessary the first time you start gnome-session with a given argument to the --choose-session option (if you save your session). As with KDE, you cannot pass an option to fvwm2. So with fvwm-themes you should add a .fvwm2rc file in ~/.fvwm constituted by the line "Read themes-rc". Here what you need in your .xsession, .Xclient or .xinitrc file with fvwm-themes:
export WINDOW_MANAGER="fvwm2"
fvwm-themes-start  --session gnome2 --no-start
gnome-session --choose-session=fvwm-themes


Since version 0.6.0 FVWM Themes has an integrated support for fvwm-ewmh. So basically you have nothing to do to enabled fvwm-ewmh. But if you upgrade you should remove in your configuration files every thing which came from sample.fvwm-ewmh (fvwm-themes uses the files in the directory $FT_DATADIR/themes/settings/ewmh/). You can check if such support is enabled with the Theme management menu (Current -> settings -> "Extended WM Hints"). If the "Extended WM Hints" entries does not appear in this menu "refresh with no cache".

Remember that if you run a desktop application, then to get the fvwm-themes menus you should use the "Alt" modifier in addition of the mouse click.

To customize your fvwm-ewmh configuration you should use the file $FVWM_USERDIR/themes/personal/ewmh-extra ("refresh the current theme" and select it when you create this file and select this file each time you modify it). Here my ewmh-extra file:

### Layer
# You do not like stays on top application
*FvwmNetHints: AcceptStaysOnTop False

# Then, you may want that kicker (and its goodies) be autoraised:
# for that you need to add the following in autoraise-extra:
#AddToFunc   FuncFvwmModulesAutoRaise
#+ I Current (kicker) Raise
#+ I Current (gnome-panel) Raise
#Style "kicker" MouseFocus
#Style gnome-panel MouseFocus

### Number of desktop
# You want more than 4 desktops (here 6)
#*FvwmNetHints: NumberOfDesktops 6

# Or you prefer that the value  of  the  previous option to be ignored and
# replaced by the number of desktops you got when you leave FVWM:
*FvwmNetHints: UsePersistentNumberOfDesktops True

### Animation
# This is set automatically if you use ksmserver as variant for
# settings -> Session Manager. You should add this with gnome
#*FvwmNetHints: NoIconAction SendToModule FvwmAnimate animate

### For better windows names
*FvwmNetHints: UseExtendedName True

### For more custumization: man FvwmNetHints

Of course you can still use the $FVWM_USERDIR/.fnh-* files.

For running fvwm-themes with KDE (via ksmserver) or with GNOME (via gnome-session) read the previous sections. Moreover, you should select the following settings:
with KDE and with GNOME. Also you can disable fvwm-themes background (for fvwm transparency): and when you have choose your modules themes you should "disable" the modules (Current -> modules -> *) which are made not useful by your kicker or GNOME panel configuration (I use modules@olicha with all modules disabled but the pager).


Q: Why fvwm-ewmh is not incorporated in the FVWM source tree?

A: Because FVWM is/was under feature freeze when I wrote this module. The current developpement version of fvwm (the 2.5.x series) has native ewmh support. This support does not use a module, it is fully incorpored in fvwm main module.


Q: Why a module?

A: Because I prefer to do as minimal change as possible to FVWM source. Also, it is more easy for development, when I make a mistake FVWM does not crash and I can restart FvwmNetHints. However, using a module is not the perfect solution. So, when I wrote the ewmh support for the fvwm 2.5 series I do not use a module.

FVWM Themes Banner SourceForge Logo FVWM Banner