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

Bug #29560 reported by seguso
94
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Metacity
Confirmed
Wishlist
One Hundred Papercuts
Won't Fix
Undecided
Unassigned
metacity (Ubuntu)
Triaged
Wishlist
Unassigned

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.

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in metacity:
status: Unconfirmed → Confirmed
Changed in nautilus:
assignee: nobody → desktop-bugs
status: Unconfirmed → Confirmed
Revision history for this message
Daniel Holbach (dholbach) wrote :
Changed in metacity:
status: Unconfirmed → Confirmed
Revision history for this message
Daniel Sargeant (dsargeant) wrote :
Changed in metacity:
status: Confirmed → Triaged
Revision history for this message
perfran (perfran) wrote :

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

Revision history for this message
Marnanel Thurman (marnanel) wrote :

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

Revision history for this message
perfran (perfran) wrote :

Thank you Thomas

Revision history for this message
Marnanel Thurman (marnanel) wrote :

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

I learned quite a lot myself writing that!

Revision history for this message
frizzle21 (frederik-nnaji) wrote :

thanks for the excellent article ;)

Revision history for this message
frizzle21 (frederik-nnaji) wrote :

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

Revision history for this message
Marnanel Thurman (marnanel) wrote :

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.

Revision history for this message
Marnanel Thurman (marnanel) 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.)

Revision history for this message
frizzle21 (frederik-nnaji) wrote : Re: [Bug 29560] Re: drag & drop improvement: delay bringing window to front until mouse released

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

Revision history for this message
Vish (vish) wrote :

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.

Revision history for this message
Vish (vish) wrote :

*ease-of-use

Revision history for this message
X (axcoro) wrote :

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

Revision history for this message
Zach (uid000) wrote :

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.

Revision history for this message
Apreche (apreche) wrote :

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.

Revision history for this message
Zach (uid000) wrote :

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

Christian Reis (kiko)
Changed in ayatana:
status: New → Invalid
Deryck Hodge (deryck)
affects: dead-ayatana → hundredpapercuts
Revision history for this message
Vish (vish) wrote :

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

Changed in hundredpapercuts:
status: Invalid → Won't Fix
tags: added: ayatana
Revision history for this message
CYREX (phoenix3dx) wrote :

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.

Revision history for this message
frizzle21 (frederik-nnaji) wrote :

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

Changed in metacity:
importance: Unknown → Wishlist
Changed in metacity (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.