Re: Still need a hint for undecorated windows

[Philipp Lohmann - Sun Germany - ham02 - Hamburg <Philipp Lohmann Sun COM>]

Carsten Haitzler (The Rasterman) wrote:
> On Fri, 01 Jul 2005 11:30:26 +0200 Philipp Lohmann - Sun Germany - ham02 -
> Hamburg <Philipp Lohmann Sun COM> babbled:
> 
>>Not really. As i said the popups would close when the application window
>>lost focus. When you go "mousing around" as you say that's exactly what
>>should happen, either because you click into another application or
>>because there's one of the "focus follows mouse" variants active.
> 
> 
> 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).

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

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

Kind regards, pl

-- 
The major difference between a thing that might go wrong and a thing
that cannot possibly go wrong is that when a thing that cannot possibly
go wrong goes wrong, it usually turns out to be impossible to get at
or repair.   -- Douglas Adams