FvwmNetHints

Section: User Commands (1)
Updated: 2 July 2001
Index

 

NAME

FvwmNetHints - a FVWM module to handle Extended Window Manager Hints. This allows, for example, to run FVWM with KDE version >= 2 and GNOME 2.

 

USAGE

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.

 

DESCRIPTION

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.
   

CONFIGURATION OPTIONS

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.

*FvwmNetHints: NumberOfDesktops n
Where n is a positive integer which defines the number of desktops you want to see in a compliant pager. This number can be changed by a compliant pager or if you go to a FVWM desktop m > n-1. Negative FVWM desktop are ignored (not supported by the spec.) and for technical reason this number is limited to 100. This option is totally dynamic. Default is 4.

*FvwmNetHints: UsePersistentNumberOfDesktops bool
Where bool is either True or False. If set to True, then when you (re)start FVWM (in fact FvwmNetHints) the value of the previous option is ignored and replaced by the number of desktops you got when you leave FVWM (in fact FvwmNetHints). If bool is False this feature is disabled. Default is False.

*FvwmNetHints: AcceptDesktopGeometry bool
Where bool is either True or False. A compliant pager can ask to change the geometry of the virtual desktop (defined by the DesktopSize fvwm2 configuration command). If bool is True we accept such a query, if False we ignore it. Default is False.

*FvwmNetHints: AcceptStaysOnTop bool
Where bool is either True of False. If True we accept stays on top hints, if False we ignore these hints (we always accept "user" stays on top hints). Default is True. (note: this hint is not a part of the EWMH but it is used). This option is totally dynamic.

*FvwmNetHints: StaysOnToplayer layer
Where layer is a positive integer which defines the layer used by a stays on top hints. By Default the initial default FVWM top layer (i.e., 6).

*FvwmNetHints: StaysPutLayer layer
Where layer is a positive integer which defines the layer of a normal application. By default the initial default FVWM stays put layer (i.e., 4). This is useful if you change the default layer with the DefaultLayers fvwm2 configuration command.

*FvwmNetHints: ActivateWindowCmd cmd
Where cmd is a fvwm2 command (complex or builtin function) to be used when a compliant application ask to activate a window. Default is "Iconify Off, Focus, Raise". Warning: Use of the former syntax that allowed to use comma separated lists of commands is strongly discouraged due to synchronization problems with fvwm. Please use complex fvwm functions instead (defined with the AddToFunc command of fvwm).

*FvwmNetHints: CloseWindowCmd cmd
Where cmd is a fvwm2 command (complex or builtin function) to be used when a compliant application ask to close a window. Default command is "Close".

*FvwmNetHints: UseWorkingAreaMaximizing bool
Where bool is either True of False. If bool is True, then when a compliant application ask to maximize a window (or if you use the FvwmNetHints Maximize command) then the working area is used in the place of the full screen for the maximizing operation. If bool is false this feature is disabled. Default is true.

*FvwmNetHints: MyStrut left right top bottom
Where left, right, top and bottom are positive or null integer which represent an area in pixels from the left of the screen to left, from the right of the screen to right, from the top of the screen to top and from the bottom of the screen to bottom. This area is added to the strut area which is computed from the compilant application WM_STRUT hint. The strut area is the area from which the working area is defined: the working area is the complement of the strut area vs the screen. This option is totally dynamic.

*FvwmNetHints: StrutOverride
Where bool is either True of False. If bool is True, then FvwmNetHints take in account only the MyStrut FvwmNetHints configuration option to compute the working area. Default is False. This option is totally dynamic.

*FvwmNetHints: UseDynamicMaximizing bool
Where bool is either True of False. If bool is True, then if the working area change (e.g., the user mask a panel) the maximized windows are re maximized with respect to the new working area. If bool is false this feature is disabled. Default is True.

*FvwmNetHints: DefaultMaximizePercentage width height
Where width and height are positive integers which are expressed as percentage of the working area (or full screen if UseWorkingAreaMaximizing configuration option is set to false). These value are used when a compliant application ask for maximizing (fully, horizontally or vertically) a windows. See also, the Maximize FvwmNetHints command. Default is 100 100.

*FvwmNetHints: UseWorkingAreaPlacement bool
Where bool is either True of False. If bool is True, then new windows are placed again to respect the working area. Default is True. If bool is False this feature is disabled.

*FvwmNetHints: SendMiniIcon arg
Where arg is either True, All or False. FvwmNetHints can send to fvwm2 (and so to all FVWM modules) the mini icons that an application provide (by a hint). This mini icon can also be resized (use the next option to define the size of the mini icons). If arg is True this feature is enabled, if arg is False this feature is disabled. Moreover, if arg is All the feature is enabled, but in addition the mini icon that fvwm2 used (defined by the MiniIcon Style option) are also send back to fvwm2 after resizing.

*FvwmNetHints: MiniIconSize width height
width and height of the mini icons send by FvwmNetHints to fvwm2. If 0 is used then the original size is preserved. Default is 16 16. This option is totally dynamic.

*FvwmNetHints: MiniIconOverride arg
Where arg is either No, Add, Size or All. This is a kind of converse of the SendMiniIcon configuration option. FvwmNetHints can set a mini icon hint to an application so that a compliant pager or task bar can display the mini icon specified by the MiniIcon Style command. If arg is No this feature is disabled. If arg is Add, such a hint is set only for application without a mini icon hint. If arg is Size, such a hint is set for applications without a mini icon hints with a mini icon which is contained in an AxA square, where A is the integer defined by the MaxMiniIconSize configuration option (A is equal to 22 by default). If arg is All such a hint is set for all applications.

*FvwmNetHints: IconOverride arg
As above for icons (remove mini and replace "contained in a AxA square" by "not contained in a AxA square").

*FvwmNetHints: MiniIconMaxSize size
Where size is a positive integer which defines the maximal size for which an icon hint is considered as a mini icon hint (see the MiniIconOverride option). Default is 22.

*FvwmNetHints: UseExtendedName bool
Where bool is either True of False. If bool is True, then windows and icons names may be modified by adding a string of the form "(i)" where i is an integer so that two windows never had the same name. More technically, this option enabled the NET visible (icons) names which needs conversion between string encoded with your charset and UTF8 string. This can cause problems for various reasons which can be solved by compiling FVWM with multibyte enabled, by using the good local (via the LC_CTYPE environment variable) or/and by using appropriate fonts for your icons and windows titles. If bool is False this feature is disabled. Default is False.

.".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 action
Tells FvwmNetHints to do action when a NoIcon style window is iconified or de-iconified. Relevant coordinates are appended to action so that the icon can be traced to a button of a compliant task bar which has set the appropriate hint. An example action is:

*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.

*FvwmNetHints: NoIconWindowName name
No yet implemented.
 

 

FVWM NET HINTS STYLES

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).

*FvwmNetHints: DesktopNetStyle styles
Apply FvwmNetHints style styles to compliant application of Desktop type. The default is: "Sticky, CirculateSkip, WindowListSkip, NoFocus, NoTitle, NoBorder, NoOverride". Layer cannot be changed and is set to 0.
 
*FvwmNetHints: MenuNetStyle styles
As above for window of Menu type. Default: "Sticky, CirculateSkip, WindowListSkip, NoFocus, NoTitle, NoBorder, NoOverride, Layer l" where l is the default (initial) fvwm2 default stays on top layer.

*FvwmNetHints: DockNetStyle styles
As above for applications of Dock type. Default: "Sticky, CirculateSkip, WindowListSkip, NoFocus, NoTitle, Border, NoOverride, Layer -1".

*FvwmNetHints: ToolBarNetStyle styles
As above for applications of ToolBar type. Default: as for applications of Dock type.

*FvwmNetHints: DialogNetStyle styles
As above for windows of Dialog type. Default: "Slippery, CirculateHit, WindowListHit, Focus, Title, Border, NoBorder, NoOverride, Layer -1".

*FvwmNetHints: ModalNetStyle styles
As above for windows with Modal state. Default is "Sticky, CirculateHit, WindowListHit, Focus, Title, Border, NoOverride, Layer l" where l is the default (initial) fvwm2 default stays on top layer.

 

COMMANDS

The following FVWM command may be executed at any time. It may be bound for example to a button menu item or typed into a module such as FvwmConsole.

SendToModule FvwmNetHints Maximize [bool] [horiz] [vert]
Similar to Maximize fvwm2 command, but (i) the working area is used instead of the full screen (if UseWorkingAreaMaximizing configuration option is set to True); (ii) horiz and vert, if given, should be percentage (of the working area); (iii) if horiz and/or vert is not given the value given by the DefaultMaximizePercentage configuration option is used (default is 100 100). You may want to replace the Maximize fvwm2 command by this command in the .fnh-start file (and reestablish the fvwm2 command in the .fnh-stop file).
SendToModule FvwmNetHints Ping [action] [time-out]
Where action is either Info, Delete, Close, Destroy, PingTerm, PingKill and where time-out is a positive integer (5 by default) which represent a time out in second. Basically, you may want to replace the "Delete", "Close" and "Destroy" fvwm2 commands by this command with the corresponding action.

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).

SendToModule FvwmNetHints ReloadPConfig
Reload the persistent configuration file. See the PERSISTENT CONFIGURATION FILE section for more details.

SendToModule FvwmNetHints ReadStartFile
Read the file .fnh-start if there is such a file in your $FVWM_USERDIR. The difference with a command as Read .fnh-start Quiet is that the search path is different (FvwmNetHints search .fnh-start only in the $FVWM_USERDIR) and that with the FvwmNetHints command the file is read only if FvwmNetHints run (and this command as no effect if FvwmNetHints does not run). This command can be used to reload the .fnh-start file if it happen that some file you read destroy the .fnh-start configuration (as a FVWM Themes theme switching). See the START/STOP CONFIGURATION FILES for more details.

SendToModule FvwmNetHints ReadStartDesktopFile
As above for the .fnh-desktop-start file, but in addition the file is read only if there is a Desktop application on your root window.

SendToModule FvwmNetHints Quit
Stop FvwmNetHints hints. This command is better than KillModule FvwmNetHints because with the FvwmNetHints Quit command the .fnh-stop and .fnh-desktop-stop can be read by fvwm2 which is not the the case with the KillModule command.

 

START/STOP CONFIGURATION FILES

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: SystemStartStopFiles name
If name is not null this cause fvwm2 to read (Quietly) the file name-start (repectively, name-stop) before reading .fnh-start (respectively, .fnh-stop). The usual FVWM search path is used.

*FvwmNetHints: SystemDesktopStartStopFiles name
If name is not null this cause fvwm2 to read (Quietly) the file name-start (repectively, name-stop) before reading .fnh-desktop-start (respectively, .fnh-desktop-stop). The usual FVWM search path is used.

 

PERSISTENT CONFIGURATION FILE

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.

DesktopName d Name
Define the name of the desktop number d to be Name (the number of the first desktop is 0). Name should be an utf8 string, you need an utf8 editor as yudit (ftp://MetaLab.unc.edu/pub/Linux/X11/editors) for non ASCII characters.

NumberofDesktop d
Where d is a positive integer which defines the number of desktops you want to see in a compliant pager. You must set the UsePersistentNumberOfDesktops FvwmNetHints configuration option to True so that this line is taken in account (if not the NumberOfDesktops FvwmNetHints configuration option is used).

 

BUGS

This module is beta please report bugs to <olivier.chapuis@free.fr>. However, it works good on my machine. Patch against the English of this man page welcome!

 

AUTHOR

Olivier Chapuis <olivier.chapuis@free.fr>

 

COPYING

This module is distributed by the same terms as FVWM itself. See GNU General Public License for details.


 

Index

NAME
USAGE
DESCRIPTION
CONFIGURATION OPTIONS
FVWM NET HINTS STYLES
COMMANDS
START/STOP CONFIGURATION FILES
PERSISTENT CONFIGURATION FILE
BUGS
AUTHOR
COPYING

This document was created by man2html using the manual pages.
Time: 20:29:28 GMT, June 12, 2002
FVWM SourceForge FVWM