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

[raster redhat com]

On 12 Apr, Owen Taylor shouted:
->  
->  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.

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.

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

on the CLIENT side.. not the server/WM side.

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

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?

->  Regards,
->                                          Owen
->  

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/