Comments on: Squib of the day: Drag and drop should work properly

By: On enhancements which need changes to the EWMH - …for the adult in you

On enhancements which need changes to the EWMH - …for the adult in you — Mon, 16 Mar 2009 02:51:46 +0000

[...] 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 [...]

By: Robin

Robin — Sat, 14 Mar 2009 14:19:07 +0000

engla: The bug about Alt+Tab not working during drag and drop is here: http://bugzilla.gnome.org/show_bug.cgi?id=135056

These issues considerably lessen the usefulness of drag&drop it would be great it these were finally solved!

By: Thomas Thurman

Thomas Thurman — Mon, 09 Mar 2009 16:25:34 +0000

(Oh, and Nautilus can’t raise itself, because of focus-stealing prevention.)

By: Thomas Thurman

Thomas Thurman — Mon, 09 Mar 2009 16:24:36 +0000

@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.

By: Patrys

Patrys — Mon, 09 Mar 2009 16:19:51 +0000

@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.

By: ulrik

ulrik — Mon, 09 Mar 2009 16:12:02 +0000

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)

By: Patrys

Patrys — Mon, 09 Mar 2009 15:57:46 +0000

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

By: Bunty

Bunty — Mon, 09 Mar 2009 11:24:17 +0000

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.

By: engla

engla — Mon, 09 Mar 2009 02:37:29 +0000

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_ :-(

http://bugzilla.gnome.org/show_bug.cgi?id=44001

By: engla

engla — Mon, 09 Mar 2009 02:33:31 +0000

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
etc!

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.