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

[Lubos Lunak <l lunak suse cz>]

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

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/