doc/fvwm/icccm.xml

   1 <?xml version="1.0" encoding="UTF-8" ?>
   2 <!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
   3   "../docbook-xml/docbookx.dtd"
   4 [
   5 <!ENTITY % myents SYSTEM "../fvwm.ent" >
   6 %myents;
   7 ]>
   8
   9 <section id='icccm_compliance'>
  10 <title>ICCCM Compliance</title>
  11
  12 <para>Fvwm attempts to be
  13 <acronym>ICCCM</acronym>
  14 2.0 compliant.  Check
  15 <ulink url='http://tronche.com/gui/x/icccm/'>http://tronche.com/gui/x/icccm/</ulink> for more info. In addition,
  16 <acronym>ICCCM</acronym>
  17 states that it should be possible for applications to receive any
  18 keystroke, which is not consistent with the keyboard shortcut
  19 approach used in fvwm and most other window managers.  In
  20 particular you cannot have the same keyboard shortcuts working
  21 with your fvwm and another fvwm running within Xnest (a nested X
  22 server running in a window).  The same problem exists with mouse
  23 bindings.</para>
  24
  25 <para>The
  26 <acronym>ICCCM</acronym>
  27 states that windows possessing the property</para>
  28
  29 <literallayout remap='.nf'>
  30 WM_HINTS(WM_HINTS):
  31     Client accepts input or input focus: False
  32 </literallayout>
  33
  34 <para>should not be given the keyboard input focus by the window
  35 manager. These windows can take the input focus by themselves,
  36 however.  A number of applications set this property, and yet
  37 expect the window manager to give them the keyboard focus anyway,
  38 so fvwm provides a window style,
  39 <fvwmref cmd="Style" opt="Lenience"/>,
  40 which allows fvwm to overlook this
  41 <acronym>ICCCM</acronym>
  42 rule.  Even with this window style it is not guaranteed that the
  43 application accepts focus.</para>
  44
  45 <para>The differences between
  46 <acronym>ICCCM</acronym>
  47 1.1 and 2.0 include the ability to take over from a running
  48 <acronym>ICCCM</acronym>
  49 2.0 compliant window manager; thus</para>
  50
  51 <command>fvwm; vi ~/.fvwm/config; fvwm -replace</command>
  52
  53 <para>resembles the
  54 <fvwmref cmd="Restart"/>
  55 command.  It is not exactly the same, since killing the previously
  56 running wm may terminate your X session, if the wm was started as
  57 the last client in your
  58 <filename>.Xclients</filename> or <filename>.Xsession</filename>
  59 file.</para>
  60
  61 <para>Further additions are support for client-side colormap
  62 installation (see the
  63 <acronym>ICCCM</acronym>
  64 for details) and the urgency hint. Clients can set this hint in
  65 the WM_HINTS property of their window and expect the window manager
  66 to attract the user's attention to the window.  Fvwm has two re-definable
  67 functions for this purpose, "UrgencyFunc" and "UrgencyDoneFunc", which
  68 are executed when the flag is set/cleared.  Their default definitions are:</para>
  69
  70 <programlisting>
  71 <fvwmref cmd="AddToFunc"/> UrgencyFunc
  72  + I <fvwmref cmd="Iconify"/> off
  73  + I <fvwmref cmd="FlipFocus"/>
  74  + I <fvwmref cmd="Raise"/>
  75  + I <fvwmref cmd="WarpToWindow"/> 5p 5p
  76 <fvwmref cmd="AddToFunc"/> UrgencyDoneFunc
  77  + I <fvwmref cmd="Nop"/>
  78 </programlisting>
  79
  80 </section>