Re: [gtk-list] Re: ICCCM compliance of GTK...

[Owen Taylor <owt1 cornell edu>]

> well according to what I have infront of me it states:
> " To applications that specify WM_TAKE_FOCUS, the window manager may
> send a ClientMessage event with the atom corrresponding to
> WM_TAKE_FOCUS in their data[0] field. If the application wants the
> keyboard focus, it should respond by calling XSetInputFocus() with its
> window argument set to the window of theirs that last had the keyboard
> focu or to their default input window and with the time argument set to
> the timestamp in the message. The revert_to argument should be set to
> RevertToParent. "
> 
> anyway. what that says to me is that a client setting the WM_TAKe_FOCUS
> property shoudl take the focus itself, if it wants if avter the
> ClientMessage form the WM, using the timestamp the WM gave it (the WM
> should use current time). Now. if the app is lagged/slow in
> responding.. and the WM (as you give the scenario below) sets the focus
> to client B after passinbg over client A and telling it to take focus..
> the timestamp on that SetInputFocus wil be before the one goign to
> client B, and thus X shoudl ignore it. That is what its desing looks
> liek to me. it does nto say the WM shoudl not use Currenttime , but
> does state clients should always use the timestamp given in the
> clientMessage sent form the WM...
> 
> so to my reading the client has to actively take part in focus setting
> If it sets the WM_TAKE_FOCUS property, otherwise it shoudl allow the WM
> to do all the focus setting and not set that atom.

[...]

> Well we may be arguing interpretations.. but the Xlib Programming
> manual (volume 1) page 421 states what I quote above. I didnt see much
> room for ambiguity there...
> 
> anyonw else want to read the icccm stuff and chime in?

I agree that that section _seems_ unambigious. However....

If you look up a few lines it says:

"Passive and Locally Active clients set the input field of
WM_HINTS to True, which indicates that they require window
manager assistance in acquiring the input focus. No Input
and Globally Active clients set the input field to False,
which requests that the window manager not set the input
focus to the top-level window."

Which certainly _allows_ the WindowManager to call 
SetInputFocus on a Locally Active client. (WM_TAKE_FOCUS
set, and wm_hints->input = True; which is what GTK does)

In fact, with your scheme, I see no difference at all between what the
ICCCM defines as a "Locally Active" client and a "Globally Active"
client, since you completely ignore wm_hints->input on WM_TAKE_FOCUS
windows. Since the ICCCM makes a big point of distiguishing between
the two in that section, and in section 4.2.7 of the ICCCM (I don't
know the page in the Xlib manual, but there is a cross-reference in
the first section), I figure that the section you quote is probably
somewhat misleading, if not erroneous.

There is also the matter of existing practice. Since current
Window Managers interpret it in the other way, if you make E
use your interpretation, you may end up with a correct, but
non-functional window manager.

But, it wouldn't hurt to make GTK call SetInputFocus in response to
the messages anyways - as long as the correct time stamp is used, it
can't cause harm, except for a bit of extra server traffic.

Are there any other toolkits that set WM_TAKE_FOCUS?

Are there any other Window mananagers that interpret WM_TAKE_FOCUS
  in your fashion?

Regards,
                                        Owen