Re: ICCCM compliance of GTK...

[Owen Taylor <owt1 cornell edu>]

raster@redhat.com said:

> On 12 Apr, Owen Taylor shouted:
> ->  
> ->  > Low-and-behold!
> ->  > 
> ->  > I have discovered the following:
> ->  > GTK is not ICCCM 2.0 compliant.
> ->  > infact no WindowManager that GTK works under (that is it can get the
> ->  > keyboard focus) is icccm 2.0 compliant.
> ->  > 
> ->  > if you read the bit about "WM_PROTOCOLS" and the "WM_TAKE_FOCUS"
> ->  > property.. you will see that if the WM_TAKE_FOCUS property is set the
> ->  > client wishes to participate in the input focus setting, so instead of
> ->  > the WM explicitly setting the focus, it sedns a client message:
> ->  > 
> ->  >    a1=XInternAtom(disp,"WM_TAKE_FOCUS",False);
> ->  >    a2=XInternAtom(disp,"WM_PROTOCOLS",False);
> ->  >    ev.type=ClientMessage;ev.window=ewin->client.win;ev.message_type=a2;
> ->  >    ev.format=32;ev.data.l[0]=a1;ev.data.l[1]=CurrentTime;
> ->  >    XSendEvent(disp,ewin->client.win,False,0,(XEvent *)&ev);
> ->  
> ->  That part of the ICCCM is certainly a bit obscure. But after
> ->  reading it a few times, I think I agree with the interpretation
> ->  of fvwm2 and currently in GTK.
> ->  
> ->   The WM should call XSetInputFocus if wm_hints->input is True, regardless
> ->     of WM_TAKE_FOCUS
> ->  
> ->   If WM_TAKE_FOCUS is true, then it should send the client message.
> 
> exactly. GTK sest the WM_TAKE_FOCUS property, but does nto seem to
> respont to clientmessage events telling it to take focus. Thats How I
> discovered this. :)

What I meant was that for what the ICCCM does _not_ require the
client to respond to WM_TAKE_FOCUS, when wm_hints->input is true.

In fact, as I read it, the client should not do SetInputFocus, unless
one of its subwindows should have the focus instead of the toplevel,
since the WM should already have called SetInputFocus.

(This situation comes up with the Plug/Socket embedding code, 
though it doesn't yet use the WM_TAKE_FOCUS event as it should;
in all current GTK code there is no need for WM_TAKE_FOCUS, but
since Plug/Socket will be incorporated into GTK, it will
be useful in the future.)

> ->  Otherwise, there would be no difference between the GloballyActive
> ->  and the LocallyActive modes mentioned in the ICCCM.
> ->  
> ->  You ask, "why the client message for LocallyActive? Isn't the FocusIn 
> ->  event enough?"
> ->  
> ->  The answer, I think, is at the end of 4.2.7 - XSetInputFocus must
> ->  have a valid timestamp, so the client cannot call XSetInputFocus
> ->  in response to FocusIn (which doesn't have a timestamp) to 
> ->  transfer the focus to a subwindow.
> 
> CurrentTime is a valid timestamp - replaced by the xserver with the
> current time...

However, the ICCCM implies that one is not supposed to use
CurrentTime. 

Imagine this - the user quickly drags across two windows:

The WM first does a SetInputFocus on client A, then on client B.
After that, client A processes its event queue and says "aha - I got a
FocusIn event, but really my subwindow should have the focus, so let
me do a SetInputFocus on the subwindow with CurrentTime." That will
have the very bad effect that the subwindow ends up with the focus,
instead of client B.

If the Client A had used a real timestamp, the problem would not have
happened, because the server would have rejected the SetInputFocus
request.

Regards,
                                        Owen