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.
