Squib of the day: Drag and drop should work properly

DragonIn GNOME bug 80984 (closely related to GNOME bug 76672), someone is asking for the window manager to help out with drag-and-drop.  The problem is that a drag-and-drop operation should not raise the window it begins in, because raising that window could obscure the window you’re planning to drop the object into.

This is a reasonable and important request.  It is, however, not at all simple.  Metacity is the program which decides whether to raise the window, and there is currently no way for Metacity to know you’re about to start a drag-and-drop operation.

One rather crappy workaround is to tell it by holding down Super or AltGr.  This works, but it’s not elegant.  The system should be able to know.

This is not what raise_on_click does.  Please forget about raise_on_click.  It won’t solve your problem.

The 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 this later with a more complicated idea called _NET_WM_MOUSE_ACTION.  Getting this into Metacity is GNOME bug 152952.  Whatever happens, it’s going to need changes to GTK and to various applications, particularly including Nautilus (the file manager).

Far more of a detailed writeup, including feedback from some of the people involved, is found in this entry. Your chronicler believes that implementing this is worth the fairly considerable effort to fix.

Photo © wili-hybrid, cc-by.

Published by

Thomas Thurman

Mostly themes, triaging, and patch review.

12 thoughts on “Squib of the day: Drag and drop should work properly”

  1. what’s wrong with raising the window that you drag from? I think the bug is that during drag you can’t use alt-tab to switch to another window, which I often workaround by dragging to the window list to raise the window I want.

  2. Looking for OS X for inspiration and awe, without trying to offend anyone, drag and drop is very much simpler.

    It is, because during dragging you can still access and browse your activities using:
    1. command-tab (alt-tab)
    2. Expose (F9 to show all windows)
    3. Switching workspaces

    This is also possible with metacity, but the activation is very awkward! You can for example, grab something to drag, then briefly hover over another window’s entry in the window list in the panel, to get that window to rise. And you can, if you have the workspace pager in the panel, do something similar with that.
    (I wrote some (old) tips and tricks here: http://kaizer.se/wiki/dragbox/ )
    The situation ain’t pretty, and if it’s not in the bug database, bringing metacity up to the standards of OSX in this regard should be on the wishlist.

  3. Another nice thing in OS X related to drag and drop was/is “spring-loaded folders” in Finder.. you would grab a file, then hover momentarily over a folder icon in Finder. Either waiting a bit or pressing space, and the folder would “spring” open, and you could dig down continuing like that, old temporary windows closing in your path behind you.

    And this feature was considered for nautilus but dropped out of _fear_ of _patents_ :-(


  4. Of course, OS X also does the very thing we want in the first place, i.e. it doesn’t raise the window that the drag begins in.

  5. Could we just raise windows on button release instead of press events? At least when clicking on contents, not on chrome.

  6. And another thing the metacity compositor should do: Apply opacity to dragged objects, at least in nautilus, so that you can see that the target really lights up, so you drop it where you think you do!

    @patrys: it is a good idea. Consider however the case where you want to do a drag movement (but not drag-grab) in the target window, like selecting files in nautilus or selecting text.. then you need the window to raise on button press. (On OSX, not an issue, since the first click is always swallowed to just raise the application; which is in part safer but not in linux/etc’s tradition)

  7. @ulrik:

    I don’t think it’s something most people expect (the unraised window drag-selection) but still nautilus would receive the event and could raise itself immediately if needed.

  8. @Patrys, @ulrik:

    See the linked overview where I wrote:

    What isn’t a solution

    * Always raising the lower window only on release, not on click (suggested by many people). This would solve the problem at the cost of weirding everyone out, not just breaking the expectations of existing Metacity users and users from other window managers in the world of free software, but also the expectations of Mac and Windows people.

Leave a Reply

Your email address will not be published. Required fields are marked *

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.