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

[raster redhat com]

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

but it requests the WM not do it.. it allows it.. but it prefers the WM
not to.. liek most of iccm it's a "do it if you HAVE to but i'd rather
you don't. 

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

true.. I have alreeday had to pull some strings for Xv which isn't icccm
2.0 compliant. i
'm mainly bringing this up as a "matter of correctness". It isnt often
people re-visit ICCCM - and this is the reason why.. we cna sit here
and argue interpretations.. most people just build off fvwm and take
its interperatation as "the word". i'm going back tot he book here
making 100% I'm being ICCCM compliant.. and in the process I'm
discovering some odd behavior.. and this was one.. I can leave my code
with tis current commented out "else" easily and ti works.. but i
thought it'd be good to bring it up as a matter of correctness incase
someone in future discovers some odd behavior under som weirdo display
redirection thng that works a bit like a wm and a data pipe etc. or
whatever... 

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

not that i can find on my machine right now.. so GTK is the only one
using it.. to my knowledge... so i'm wondering, seeing it's the only
one.. woudl it be "more" correct to have gtk respond to the client
message to take the focus? If you dont' think so that's fine.

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

no.. mainly because they are nearly all based on fvwm or if they behave
differently are soon modified to behave the same.. we mayaswell have
"FVWMCCCM":)


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