drag & drop improvement: delay bringing window to front until mouse released

[seguso]

Open a nautilus window and xmms. maximize natilus. Bring xmms on top (activate it). Nautilus is now on the background, yet some files are visible within it, because xmms does not cover it completely.

Now, a natural action is to drag a file to xmms playlist. This is not possible because, as soon as you click the file in the nautilus window, nautilus goes on top and (being maximized) hides xmms. So, the only way to drag is to hover the tasklist and reactivate xmms.

IMHO, a much better way exists (the one employed by MS. Windows): the nautilus window should go on top only when the mouse is _released_ (not when it is pressed). So a direct drag would be possible, without resorting to the tasklist.

[Sebastien Bacher (seb128)]

Thanks for your bug. That's known upstream: http://bugzilla.gnome.org/show_bug.cgi?id=112308

[Daniel Holbach (dholbach)]

Upstream says, it's rather: http://bugzilla.gnome.org/show_bug.cgi?id=152952

[Daniel Sargeant (dsargeant)]

Also found this upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=76672
Brainstorm idea link: http://brainstorm.ubuntu.com/idea/2567/

[perfran (perfran)]

I think the importance of this bug should be higher than "Wishlist" because it's a big usability issue for a such common thing.
Is there anything that ubuntu developers could do to accelerate the resolution of this bug upstream?
Thanks

[Marnanel Thurman (marnanel)]

@perfran: I'll write a page on blogs.gnome.org later explaining the rather complicated current state of play.

[perfran (perfran)]

Thank you Thomas

[Marnanel Thurman (marnanel)]

Here we go: http://blogs.gnome.org/metacity/2008/06/11/drag-and-drop/

I learned quite a lot myself writing that!

[frizzle21 (frederik-nnaji)]

thanks for the excellent article ;)

[frizzle21 (frederik-nnaji)]

here's the respective bugzilla page for the associated meta-bug; http://bugzilla.gnome.org/show_bug.cgi?id=133047
it's called: "Bug 133047 – Fix and improve focus handling and DnD"

i don't understand the part, why the information about DnD or not DnD operation is so crucial. Doesn't it suffice to assign behaviour via MouseButtonDown and MouseButtonRelease events?

let's hope this issue will be resolved soon, since i hear that fluxbox already handles this and it has been around for so long in gnome...

[Marnanel Thurman (marnanel)]

frederik.nnaji: I covered this in the article:

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

There are *no* other systems I'm aware of which behave this way. The Mac doesn't, Windows doesn't, Metacity doesn't, and nor does any other WM. It would solve this one problem at the cost of introducing a much larger problem.

[Marnanel Thurman (marnanel)]

Do you know for sure that fluxbox handles this? If so, I could read their code or ask their developers to find out how.

(It's not that we don't know how to do this-- we know lots of ways to do this, none of them very good. What's needed is a standard way.)

[frizzle21 (frederik-nnaji)]

oops.. my bad.
yeah, sounds conclusive to me, a scalable solution for a problem of scale..
let's see what shuttleworth's people will come up with.. i'm optimistic
about the matter..
as long as somebody has a proper severety level assigned to the problem, it
should work out in time.

On Sat, Jul 26, 2008 at 6:27 PM, Thomas Thurman <email address hidden> wrote:

> Do you know for sure that fluxbox handles this? If so, I could read
> their code or ask their developers to find out how.
>
> (It's not that we don't know how to do this-- we know lots of ways to do
> this, none of them very good. What's needed is a standard way.)
>
> --
> drag & drop improvement: delay bringing window to front until mouse
> released
> https://bugs.launchpad.net/bugs/29560
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Metacity Window Manager: Confirmed
> Status in "metacity" source package in Ubuntu: Triaged
>
> Bug description:
> Open a nautilus window and xmms. maximize natilus. Bring xmms on top
> (activate it). Nautilus is now on the background, yet some files are visible
> within it, because xmms does not cover it completely.
>
> Now, a natural action is to drag a file to xmms playlist. This is not
> possible because, as soon as you click the file in the nautilus window,
> nautilus goes on top and (being maximized) hides xmms. So, the only way to
> drag is to hover the tasklist and reactivate xmms.
>
> IMHO, a much better way exists (the one employed by MS. Windows): the
> nautilus window should go on top only when the mouse is _released_ (not when
> it is pressed). So a direct drag would be possible, without resorting to the
> tasklist.
>

[Vish (vish)]

Added this to the ayatana project , as this merits some more attention.
There have been several papercuts asking for a fix .
Fixing this will bring more easy of use for drag'n'drop.

[Vish (vish)]

*ease-of-use

[X (axcoro)]

delay the gain of the focus a couple of ms when drag is not an option?

[Zach (uid000)]

There was a post on the gnome developer blog about why this is a harder problem than it appears.
http://blogs.gnome.org/metacity/2008/06/11/drag-and-drop/

For the record this is a very, very longstanding problem in both gnome (metacity, specifically) and KDE, and it isn't as simple as it seems.

[Apreche (apreche)]

Hi, My bug #388247 was marked as a duplicate of this one. However, I do not believe that mine is actually a duplicate.

This bug, #296560, talks about a situation where people drag from a lower window to an upper window. Then the lower window steals focus when it should not do so. That is the opposite of my bug.

My bug is not about stealing focus at a bad time. It's about not stealing focus when it should be stolen. Let's say I want to drag something from an upper window to a lower one. The lower window is currently obscured by upper windows. While my drag is hovering over the lower window, that lower window should steal focus, so that I can aim my drag at a specific folder or spot in that (formerly) lower window.

Also, if I continue to drag around, any window I hover over for more than a short amount of time should steal focus.

If this explanation isn't clear, please don't hesitate to ask for clarification. Thanks.

[Zach (uid000)]

@Apreche, I agree that your bug is not a duplicate of this one. It is similar but not the same.
Yours is a longstanding gnome bug:
http://bugzilla.gnome.org/show_bug.cgi?id=132339
This gnome bug is cited near the end of the gnome developer blog post I linked to above.

[Vish (vish)]

Won't Fix in papercuts , but is tagged "ayatana" to be overseen in Ayatana project

[CYREX (phoenix3dx)]

Was going to report this. In my case i have the movie player open and nautilus in the background, i would like to drag and drop several movies in the playlist of movie player without losing focus on movie player. In this case movie player is in the front and nautilius is maximized and in the background but when i click on it to drag the movies a loose focus of movie player.

[frizzle21 (frederik-nnaji)]

i hope Pranav Mistry's F/OSS work will be included in this lovely Ayatana project, before he goes Nobel Prize..