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



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. 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 timing-based behavior is likely to run into problems with race conditions and also accessibility problems. I shudder at the thought of anything in the window manager (besides perhaps alert beeps/flashes) relying on timeout periods.

- Bill



    John

_______________________________________________
wm-spec-list mailing list
wm-spec-list gnome org
http://mail.gnome.org/mailman/listinfo/wm-spec-list






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]