On Fri, 01 Jul 2005 12:21:50 +0200 Philipp Lohmann - Sun Germany - ham02 - Hamburg <[EMAIL PROTECTED]> 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) [EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) _______________________________________________ wm-spec-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/wm-spec-list
