desktop-packages team mailing list archive

[Pedro Villavicencio <pedro@xxxxxxxxxx>]

*** This bug is a duplicate of bug 29560 ***
    https://bugs.launchpad.net/bugs/29560

** This bug has been marked a duplicate of bug 29560
   drag & drop improvement: delay bringing window to front until mouse released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to metacity in Ubuntu.
https://bugs.launchpad.net/bugs/70419

Title:
  Wish: Improve drag&drop: raise window on mouseup & drag&drop

Status in The Metacity Window Manager:
  Confirmed
Status in “metacity” package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: metacity

  I suggest having windows raised not on mouse-button-down (as they are
  now), but in mouse-button-up; making that the default behavior and/or
  adding an option to turn it on.

  Furthermore, I suggest raising windows if the cursor stays over them
  for a few seconds when in a drag&drop operation.

  Rationale:

   - There are two main "click" operations which can be done in a
  window: click (button down, button up) and drag (button down, move
  mouse holding button), as in drag&drop operations.

   - If the user clicks in a window, the new behavior would be almost
  the same as it is now, with no noticeable differences other than the
  (very small) delay between mouse-down and mouse-up.

   - If the user wants to do a drag&drop operation, the new behavior
  would allow him to do the drag&drop between _all visible items_ the
  moment the operation begins, whereas the old behavior does not.

  Say you have two partially overlapping Nautilus windows open. In the
  one in the foreground there is a folder, and in the one in the
  background there is a file which is not obscured by the foreground
  window. You want to drag that file to the folder. With the current
  behavior, clicking and dragging on the file immediately raises the
  background window, changing the screen distribution (counter-
  intuitive) and obscuring a significant part of the foreground window
  (likely including the intended drag&drop target). With the new
  behavior, you just drag the (visible) file to the (visible) folder and
  that's it.

  Let's say now that the situation is reversed. You want to drag a file
  from a foreground window to a folder in a background window. The
  background window is obscured by the foreground window, so the target
  folder is not visible. With the current behavior the best way to
  drag&drop is either moving the windows (so the drag&drop is not
  direct) or using the task bar (rather inconvenient). With the proposed
  behavior it's just drag the file to the visible part of the background
  screen - linger for 2 seconds with the button down - the background
  screens is raised - drag to the (now visible) folder and release the
  button.

  The suggested behavior would make dragging & dropping more convenient
  and more intuitive, and I have seen it implemented to good use in
  several other file managers. I have filed the bug against Metacity
  because I suppose that it's possible to control this policy in the
  window manager.

  Thanks for your time and keep up the good work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/metacity/+bug/70419/+subscriptions