After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 96743 - Dragging Windows Between Workspaces
Dragging Windows Between Workspaces
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: general
unspecified
Other All
: Low enhancement
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 93897 (view as bug list)
Depends on: 135056
Blocks: 155458
 
 
Reported: 2002-10-24 19:49 UTC by Dave Bordoley [Not Reading Bug Mail]
Modified: 2020-11-07 12:37 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Dave Bordoley [Not Reading Bug Mail] 2002-10-24 19:49:48 UTC
I really hope i'm not opening old wounds with this bug and reading through 
the bug archives i can only find discussion of edge flipping (which this 
bug is not a request for).

Motivation:
Moving windows between workspaces is currently kind of complex and hence 
hard. metacity context menu lets you move windows between workspaces but 
require you to know the workspace number (not very intuitive especially if 
you have workspaces setup up in more than one row, how do you know what 
the workspace number is anyway?). moving windows within the workspace 
switcher is sort of hard since you need pinpoint accuracy with the mouse.

one solution i had in mind is covered in bug 96675.

Another idea is the ability to drag windows between workspaces with 
resistance at the edges of the screen to prevent users from accidentally 
dragging the window across.

The nice thing about this approach is that it allows the user to directly 
manipulate the window they wish to move and also provides the illusion of 
workspaces as a planar work area (as they are presented in the workspace 
switcher).

I'm really interested in this purely from a usability standpoint, I most 
definately don't want this to be a preference, and if prior experience 
shows that this behavior is not desirable I will be content with the 
decision. But please lets talk about it a little.
Comment 1 Mark Nelson 2002-10-30 05:06:32 UTC
I agree with Dave on this.  Getting rid of edge flipping was a good
idea.  It's bad for a number of reasons, and especially in that it
makes it impossible to use the edge to hit icons on edge panels. 
Having said that, the current methods to move windows between
workspaces is pretty crappy.  Especially trying to use the workspace
switcher.  I think this proposal is pretty good for a number of reasons:

When you are moving windows around, the prime edge realistate of the
screen is being wasted because you can't do anything while you have a
window under your control.  It would be in our best interests to use
this realistate as best we can.  Edge flipping for moving windows
around between workspaces is a great use of that space.  

It's extremely fast (no clicks required, and you have a huge target
for moving the window between workspaces).

It should be a very easy behavior to learn.  New users should be able
to pick it up quickly (no clicking required, no context menus to
navigate), and power users should be happy at the speed which the
operation can be accomplished.

Using this method and the workspace switcher, we have a fairly obvious
way to use multiple workspaces.  

Using this method and using "ctr+alt+left/right> we also have a very
fast way to use multiple workspaces.

In the end, we can't really go wrong.

Mark
Comment 2 Havoc Pennington 2002-10-30 20:54:53 UTC
The details of this are important I'm guessing. We probably want some
edge resistance, and also some sort of feedback that the workspace has
been switched, maybe some flashing in the workspace switcher, maybe 
the little popup workspace name like WindowMaker used to have 
(when switching to a new space, it flashed the workspace name onscreen 
then faded it out).
Comment 3 Heath Harrelson 2002-10-30 21:31:34 UTC
*** Bug 93897 has been marked as a duplicate of this bug. ***
Comment 4 Mark Nelson 2002-10-31 15:30:44 UTC
Havoc:

Those all seem like great ideas.  I especially like the small dialog
informing the user which workspace is being displayed.  Could we do
the same thing for the "ctrl+alt+arrow" workspace switches as well?

Mark
Comment 5 Havoc Pennington 2002-10-31 15:51:58 UTC
Ctrl+Alt+arrow already does have a popup, though it isn't quite what I
was thinking for the mouse-based switching - thinking about it now,
it's quite possible we should synchronize the popup when switching
with keyboard and when switching with mouse. i.e. pop up the same thing.
Comment 6 Mark Nelson 2002-11-01 03:59:14 UTC
Havoc: Sorry about that, I had forgotten we do have a popup with the
ctrl+alt+arrows.  Yeah, I think standardizing on one popup (for moving
windows, the ctrl+alt+arrow moves, and the workspace switcher) would
be a good idea.

Mark
Comment 7 Rob Adams 2003-03-03 06:51:35 UTC
marking low for now
Comment 8 John Richard Moser 2006-02-23 03:37:50 UTC
This is a good idea, but do remember that the user has to be able to identify what workspace they're on.  Showing the workspace switcher pop-up is one idea, but also you have to consider that the thing suddenly appearing may be a problem in and of itself:  a sudden box appearing on-screen in the MIDDLE of an action will be surprising.

Remember old edge-flipping problems with some systems.  I recall one WM edge-flipped but left the mouse on the same side of the screen; this was confusing, and led to repeated edge-flipping.

We can hit both of these problems in one go.  When the window (read: Mouse pointer) hits the edge of the screen, slide it back to the other edge to indicate that the workspace was switched; also slide all windows onscreen off, and all windows offscreen on.  The workspace switcher dialog should also slide, meaning that it will slide off-screen with a new one updated to the new focused workspace on-screen; but also, we have a way to slip it into the user's view.  We can probably slide it offscreen when the user drops the window.

The edge-flipping by sliding windows on and off screen must consider the panels.  At the moment, windows cannot have their title bars under a panel; but they are always placed below a panel if they overlap.  This is good.  From this behavior, panels never have to move on screen for the motion to make sense.

We should also consider that the mouse (while dragging a window) should stop with the window; currently if a window is dragged against a panel, the mouse pointer will leave its relative position, even coming OFF the window.  This behavior needs to be changed; the mouse pointer SHOULD move, but it should NOT leave the window.  If it moves to the edge of the window and persists to try to leave it, that should cause the edge flipping behavior.

Potentially, such visual effects as sliding windows on/off screen and sliding the workspace switcher around have consequences.  For example, if we want to slide windows as indicated, then we have to allow for windows that are half-on and half-off given workspaces; switching between these workspaces would leave those windows on screen (think of enlightenment).  Further, these effects would have to be mimicked by normal workspace switching, for consistency.  There are good and bad sides to both the generic concept of windows sliding around during a workspace switch, and windows being partially on/off workspaces (viewports).  This should be considered before adopting these visual models.
Comment 9 Calum Benson 2008-05-03 00:15:18 UTC
I have to admit, since I've started using Spaces on OS X Leopard, I really miss not being able to drag windows off the edge of the screen to move them to an adjacent workspace in GNOME... find myself trying to do it all the time!   So I for one would certainly support a bit of renewed interest in fixing this :)
Comment 10 Alexandre Franke 2008-10-21 14:38:04 UTC
Brightside (http://www.linux.com/feature/124478) seems to provide part of the feature requested here. It might be a good idea to have a look at it.
Comment 11 André Klapper 2020-11-07 12:37:18 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all
old feature requests in Bugzilla which have not seen updates for many years.

If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be implemented.