Fwd: Re: ICCCM

Thank you for your thoughts and information. I intended this to be on the  
mailing in the first place. Hope you don't mind Tuomo.

------- Forwarded message -------
From: "Tuomo Valkonen" <[email protected]>
To: Robin <[email protected]>
Cc:
Subject: Re: ICCCM
Date: Mon, 20 Oct 2008 15:01:17 +0700

On 2008-10-19 02:39 +0700, Robin wrote:
> On Tue, 14 Oct 2008 01:06:29 +0700, Tuomo Valkonen <[email protected]> wrote:
>
> >On 2008-10-13, John Harrigan <[email protected]> wrote:
> >>Both Acrobat and OpenOffice open in the 'Aux' frame as desired,
> >>but starting OpenOffice moves focus to the 'Aux' frame.  Acrobat
> >>does not change the focus.  Changing switchto from true to false
> >>doesn't seem to change this behavior.
> >
> >It is possible that OO is crap [of course it is, and utter and total
> >at that] and forces the focus, in violation of the ICCCM [1]. Focus
> >change is not a request, but a command that the X server follows.
> >ICCCM establishes protocols on when it may be used.
> >
> >  [1]: http://www.tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
> >
>
> Whenever I read that there are problems with certain apps (mostly
> gnome-based) not running properly on ion, your response is usually that
> the app is crap and does not follow the ICCCM spec.
>
> Not knowing what ICCCM means, I looked it up at
> http://en.wikipedia.org/wiki/Inter-Client_Communication_Conventions_Manual
>
> One section says:
>
> "The ICCCM is notorious for being ambiguous and difficult to correctly
> implement [1]. Furthermore, some parts are obsolete or no longer  
> practical
> to implement [2].

Says the WIMPshit desktop clique, who does not want to support
alternatives to their gnome/kde shit, and instead...

> Maybe "does neither follow the ICCCM nor the EWMH"?

... design shit like EWMH, that is very closely tied to WIMPshit
desktop metaphor.

In any case, the ICCCM is very clear here
<http://www.tronche.com/gui/x/icccm/sec-4.html#s-4.1.7>:

"""
There are four models of input handling:

   * No Input - The client never expects keyboard input. An example would be
     xload or another output-only client.
"""

The ones that normal applications should adhere to are:

"""
   * Passive Input - The client expects keyboard input but never explicitly
sets
     the input focus. An example would be a simple client with no  
subwindows,
     which will accept input in PointerRoot mode or when the window manager
sets
     the input focus to its top-level window (in click-to-type mode).

   * Locally Active Input - The client expects keyboard input and explicitly
sets
     the input focus, but it only does so when one of its windows already
has the
     focus. An example would be a client with subwindows defining various
data
     entry fields that uses Next and Prev keys to move the input focus
between
     the fields. It does so when its top-level window has acquired the focus
in
     PointerRoot mode or when the window manager sets the input focus to its
     top-level window (in click-to-type mode).
"""

There is also

"""
   * Globally Active Input - The client expects keyboard input and  
explicitly
     sets the input focus, even when it is in windows the client does not
own. An
     example would be a client with a scroll bar that wants to allow users  
to
     scroll the window without disturbing the input focus even if it is in
some
     other window. It wants to acquire the input focus when the user clicks
in
     the scrolled region but not when the user clicks in the scroll bar
itself.
     Thus, it wants to prevent the window manager from setting the input
focus to
     any of its windows.
""""

But

"""
Clients using the Globally Active model can only use a SetInputFocus
request
to acquire the input focus when they do not already have it on receipt of
one of the following events:
   * ButtonPress
   * ButtonRelease
   * Passive-grabbed KeyPress
   * Passive-grabbed KeyRelease
"""

So you see, the cases when an application is allowed to set the focus
are clear and very limited.