Re: ICCCM compliance of GTK...

[Owen Taylor <owt1 cornell edu>]

> 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.

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.

That's how I read it, anyways...
                                        Owen