On enhancements which need changes to the EWMH

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.

One Comment

  1. Posted March 16, 2009 at 10:39 pm | Permalink

    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.

5 Trackbacks

  1. […] other things, but the actual content is the business of the application.  So you need to invent a way for the WM to tell the application that a drag is happening, and for the application to tell the WM what the data […]

  2. […] …for the adult in you “Many window managers are like Marshmallow Froot Loops; Metacity is like Cheerios.” Skip to content « Squib of the Day: Maximise to the edge of the screen On enhancements which need changes to the EWMH » […]

  3. […] correct answer is fixing this in the EWMH.  Luboš had an idea about this back in 2004 called _NET_WM_TAKE_ACTIVITY, and Elijah improved on […]

  4. […] This would require a new window hint in order to work. It would replicate behaviour that is generally the province of toolbars and appears to have WONTFIX written all over it. […]

  5. […] this is a new window state, it would require a change to the EWMH, which makes it […]