GNOME Bugzilla – Bug 96743
Dragging Windows Between Workspaces
Last modified: 2020-11-07 12:37:18 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.
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
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).
*** Bug 93897 has been marked as a duplicate of this bug. ***
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
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.
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
marking low for now
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.
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 :)
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.
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.