You seem to be talking about raising other windows when the mouse enters them during DND operations. That’s not really what this post was about (though Thomas did refer to it; see the bug 112308 reference near the end). And the problem in that case is that we don’t know when the mouse enters the window, due to how grabs & X11 work. (Though, yes, the Metisse folks apparently figured out something clever with the XFixes extension…)

The problem being discussed is about not raising windows on mouse button press, when that button press could begin a DND operation. (It would instead be raised on mouse button release, if no DND operation was started between the button press and button release.) The problem here is that the WM needs some kind of hint from the app about whether certain button press/release combos could start a DND operation and whether they actually did. That info isn’t currently available to the WM.

Just my opinion as a user. I do not code in C or anything that complex.

Metisse currently listens for DnD events using XFixes (although a better solution such as _NET_WM_MOUSE_ACTION is *definitely* needed).

As for the interaction, we are currently implementing the following inside Metisse’s window manager:
– during the drag, hovering and staying still over a window will bring it on top after a timeout,
– if at the end of the drop, the user clicks on the destination window after the drop (within say 500ms), then the destination window stays on top,
– if the user does not click before the timeout, the window stacking is restored to what it was before the drag operation started.

The folding operation Frederic and I both described is only used in Metisse for text selection operations (see Fred’s URLs) but it can also be used for drag and drops : http://www.lri.fr/~dragice/foldndrop/ (this works great but we are working on a faster solution for Metisse, one that could be more easily picked up by Metacity)

That quote of mine was from Oct 2005; comment 28 of bug 154260 is from May 2006. The original _NET_WM_MOUSE_ACTION, to be fully implemented, would take an unrealistic amount of work, but implementing just the sane subset is already nearly done. So, yeah, it was a chronological thing. :-)

1) Not being able to click a button that was enabled while cursor was already over it

2) Not being able to prevent click-through for critical buttons in a lowered window (for example a “delete all” button should be drawn as enabled but should only react to clicking and hovering when the window is the active – same as similar buttons behave on OS X)

All three of these could be addressed if GDK was able to track the cursors (think MPX) for all interactive controls and set appropriate hints on the window (mouse1 is over a draggable element, do not raise unless released, mouse2 is over a button that could lead to accidental data loss, mouse3 works as usual).

You can check a screencast at :
http://www.dailymotion.com/relevance/search/metisse%2Bmandriva/video/x11e0x_mandriva-linux-2007-metisse-copy-pa_tech

Oh, the reason I said it would take a great deal of work was a quote from you here:

“Owen did not like the hack at all, and thus _NET_WM_MOUSE_ACTION was born. Unfortunately, that one was tough with lots and lots of work needed for it.”

Maybe I misunderstood the context or something, or took it out of chronological sequence.