Re: Still need a hint for undecorated windows

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Fri, 01 Jul 2005 12:21:50 +0200 Philipp Lohmann - Sun Germany - ham02 -
Hamburg <Philipp Lohmann Sun COM> babbled:

> > but the app was losing focus for a very good reason - the wm was obeying its
> > focus policy. the way menus were done was such that displaying the menu
> > would validly trigger the focus policy - and the wm has no way of knowing
> > otherwise if it should really remove the focus or not because it has no idea
> > what this new override redirect window is - just that the client app window
> > got a leave event and not due to a grab etc.
> 
> We're mixing two things here. As you correctly say the original popup
> implementation without grabbing had its drawbacks in "focus strictly
> under mouse" case, because leaving the window even when entering just
> the override redirect popup would cause the WM to take the focus out of
> the app window. Still i got the focus into the popup which was IMHO a
> bug in the WM (metacity in that case).

it would also have problems in many other cases - like if menus extend beyond
the parent window's boundaries the mouse will go over other clients possibly
while traversing from menu to submenu and thus cause a focus change and bring
the menu down :) either way - making the grab method happen is the right thing
to do (tm)

> >>>nb - its not that wm's set focus TO the override redirect window - they see
> >>>the mouse EXIT the app window for a reason other than a grab and go "ooh -
> >>>mouse exited the app - must remove focus" and so ooo loses the focus - thus
> >>>control over keyboard and thus decided it is time to give up on menus :)
> >>
> >>That's your theory. The XEvents i received said that the popup got the
> >>focus. With all due respect i'll trust the Xserver more than your theory ;-)
> > 
> > 
> > not theory - i was wathcing the events from the wm's side and was using xmon
> > logs too. i was working with my wm and ooo - i knwo what was happening.
> > enlightenment gor a mouse out from the app window (as it entered the menu
> 
> See above: the original WM i encountered the problem with was metacity
> :-) And yes, even if the focus wouldn't have come to the popup it still
> would have left the application window.

weird. well i do know e wasnt setting the focus - the focus si only set in a few
places int he code and that didnt get triggered as i was logging it :)

> > window) BUT the mouse leave DETAILS and MODE did not indicate a grab - they
> > simply indicated the same kind of mouse out you would get with the window
> > entering any other widnow on screen that may become overlayed above the
> > client the mouse was over (a new window, etc.). e went "ooh mouse out"
> > obeying strict pointer focus and thus ooo lost the focus - closing its menu.
> > at this point the menu window was closed - e got the mouse in again for the
> > app and slapped focus back onto ooo. the fact is the events do not help you
> > differentiate if this window was a menu window for the app or some other
> > override redirect window some other program put up (some splash screen or
> > something that isnt managed). :)
> 
> Undoubtedly. But my original point was just to say that
> applications/toolkits have to grab the pointer, because else the WM will
> mess their popups up. I just reacted to Mr. Pennington saying "apps want
> to grab the pointer".

well not just the wm - but other apps could too. :) its the price you pay living
in a windowing system where theres more than just your app :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com
裸好多                              raster deephackmode org
Tokyo, Japan (東京 日本)