Re: proposal for a smarter behavior for raising windows on mouse click

[Rob Adams <readams readams net>]

That protocol would work, so long as the specification states that a
window advertising support for _NET_WM_HANDLE_RAISE MUST raise the
window if it doesn't start a drag operation, or something like that.  We
want to maintain the fact that raise-on-click is a window manager policy
decision, and not an application policy decision.

On Thu, 2004-01-29 at 04:59, Lubos Lunak wrote:
> On Tuesday 27 of January 2004 23:33, John Harper wrote:
> > On Jan 27, 2004, at 12:19 PM, Lubos Lunak wrote:
> > > On Tuesday 27 of January 2004 21:01, John Harper wrote:
> > >> sawfish implements something similar, it has a
> > >> _SAWFISH_WM_RAISE_WINDOW
> > >> wm protocol. When windows advertise they support it, user-initiated
> > >> window raises are redirected to the client window, similar to how
> > >> WM_TAKE_FOCUS works
> > >>
> > >> The motivation for adding this was to do drag and drop correctly in
> > >> nautilus (the version based on gtk 1.x). However, getting things to
> > >> work correctly was fraught with race conditions, so something more
> > >> under wm-control may be better..
> > >
> > >  Could you please list the problems? I think I can already see some of
> > > them,
> > > but you have had the personal experience ;), so you know them all.
> > > That'd
> > > certainly help to find out how to do it better.
> >
> > the nautilus code has some comments describing some of the issues I ran
> > into:
> >
> > http://cvs.gnome.org/bonsai/cvsblame.cgi?file=nautilus%2Flibnautilus-
> > extensions%2FAttic/nautilus-drag-window.c&rev=&root=/cvs/gnome
> >
> > I think the main thing was that the code worked by receiving the
> > raise-window message, then waiting a period of time for a
> > button-release event, but there were cases when the button-release
> > event never arrived.
> 
>  How could this be? AFAIK the window that gets ButtonPress gets all mouse 
> events until ButtonRelease, unless there will be a grab on another window as 
> a result of the ButtonPress, or the window gets unmapped (which is both ok in 
> this case as far as I can say). Are you sure the matching ButtonRelease 
> didn't simply get filtered out somewhere else in the application? I tested it 
> a bit with Konqueror, and it didn't seem to ever miss ButtonRelease (with the 
> exception of the above-mentioned unmap after switching virtual desktops, 
> which a) doesn't really matter it, b) will be taken care of in next Qt 
> version anyway).
> 
>  In case this was just your mistake, I think it could be quite simple:
> - apps specify (let's say) _NET_WM_HANDLE_RAISE in their WM_PROTOCOLS
> - when the WM intercepts a click inside a window, it first replays 
> (XAllowEvents) the click (if it passes such clicks to apps), and then sends 
> _NET_WM_HANDLE_RAISE to the app, with the ButtonPress timestamp (if the WM 
> raises on clicks, that is)
> - the app first receives the replayed ButtonPress, and then it gets 
> _NET_WM_HANDLE_RAISE, it resets some variables related to this (whether dnd 
> was started, etc.)
> - if DND is started, etc. it sets the matching variable
> - when the app gets ButtonRelease, and there was DND or whatever, it does 
> nothing, otherwise it raises the window with the timestamp from 
> _NET_WM_HANDLE_RAISE
> 
>  Can anybody see a problem with this? I'll see if I get today to writing a 
> patch for Qt and KWin to try this for real.
> 
> > Also, there were problems with making sure the 
> > correct timestamp got passed when actually focusing/raising the window
> > (e.g. you really want XRaiseWindow to take a timestamp like
> > XSetInputFocus does)
> 
>  The 1.3 draft actually has this, _NET_RESTACK_WINDOW. But the WWW pages are 
> somewhat not up to date - could whoever knows how to do it please sync them 
> to current CVS? Hmm, and I also see that it doesn't say that 1.3 is only a 
> draft yet :-/.