Some of the enhancements which have been suggested need some sort of hint to be set on windows. For example, the recent squib about a special style for warning windows could only work if warning windows were marked in some way, and at present they’re not. Similarly, drag and drop can only work better if the window manager is warned which clicks start a drag and which don’t. This too will need a new hint.
There are two ways this can be done. The simplest way is to use a hint whose name begins _METACITY; this doesn’t require us to talk to anyone. It’s sometimes one way of starting the process of adding a feature like this. Of course, it means that the feature’s unlikely ever to work with any other window manager.
The better and more extensible way is to make a new standard hint, one beginning _NET_WM. This means adding the hint to the Extended Window Manager Hints standard (the EWMH). Changing this standard means arguing it out on the wm-spec list. The maintainers would like not to be the only ones to raise new ideas on this list.
In either case, the toolkits (such as GTK) will then need to be updated to mark the relevant windows with the relevant hints, and finally the applications will probably need to be updated to use the new functionality in the toolkits. You can see, gentle reader, that enhancements like these are the source of more work than the average enhancement. They may nevertheless be worth the effort.
This entry exists mainly so that we can link to it when the issue comes up.
Photo © !!sahrizvi!! (back in Dubai) !!, cc-by-nc-nd.
I still don’t see why drag and drop requires that the drag not to raise the source window.
Either way you have 2 windows, the current behavior is that the source window is raised which may obscure the target window, so to make it work you need to make sure even with the source window on top, the drop target is still visible. Or that you can somehow get the target window to raise after the drag has been initiated [1].
Suppose a EWMH flag is added so that the drag no longer raises the source window, how will one perform a drag and drop operation then? The only time this flag is useful is when the target window is on above the source window already, which means the drag source cannot be obscured by target window.
So adding the flag changes the requirement from:
a) the drop target cannot be obscured by the source window
to:
b) the drag source cannot be obscured by the target window
And I just don’t see how b) is better than a).
[1]: currently you can do that by dragging it to the window list, which will raise the target window. It’s unfortunate that normal keyboard shortcuts like alt-tab (and other workspace switching shortcuts too) don’t work after a drag has been initiated.