GNOME Bugzilla – Bug 665764
Alt+Ctrl+Shift+Up on first workspace
Last modified: 2015-03-26 18:23:43 UTC
Presently (as far as I know) it's only possible to create a new workspace at the end of the workspace list. Bug 646409 has some ideas about that. Here is another: If I have a window focused on the first workspace, along with at least one other window, and I press Alt+Ctrl+Shift+Up, a new workspace should be created above the first workspace and the current window should be moved onto it. The only negative point I could see here is that it may interfere with someone who wants to take a window from some workspace far down (ie: more than 2) and 'slam it to the top' by holding down Alt+Ctrl+Shift and pressing 'up' a bunch of times. Fitts' keyboard law, if you will. That could be dealt with by requiring the user to release and re-press Alt+Ctrl+Shift before a new workspace is created, in this case.
One thing that's nice about this feature that just came to mind: it's completely reversible in an absolutely intuitive way.
This is a dupe of https://bugzilla.gnome.org/show_bug.cgi?id=649585 it seems. I thought this was a bug as well but it might be by design? It does seem counter-intuitive that it allows it to go down but not up - maybe this could be a gnome-love task?
Makes sense to me, if adequate feedback can be given about what's happening. We don't do a fantastic job of communicating moving windows across workspaces, unfortunately...
(In reply to comment #3) > Makes sense to me, if adequate feedback can be given about what's happening. We > don't do a fantastic job of communicating moving windows across workspaces, > unfortunately... My "feedback", I mean that we need to visually communicate that the window is being moved from the first to the last workspace. Some time ago, we had designs that showed the workspace being zoomed out very slightly for transitions: https://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/workspace-switcher.png One possibility would be to resurrect that visual treatment and use it here. CC'ing Jakub to get his view.
please use keyboard combos using meta for shell operations
(In reply to comment #4) > (In reply to comment #3) > My "feedback", I mean that we need to visually communicate that the window is > being moved from the first to the last workspace. This is not what I wanted to request. I rather want for a new "first workspace" to be created on top. The existing work spaces are "moved down" (ie: workspace 1 becomes workspace 2, 2 becomes 3, etc). The window is then moved into this new first workspace.
(In reply to comment #5) > please use keyboard combos using meta for shell operations Ctrl+Alt+Shift+Up is already an existing key binding -- it works on all of the other workspaces except for the first one. This bug is only about making that existing shortcut useful on the first workspace as well.
I like the suggested behavior, including the requirement of the window needing to originate on the topmost workspace to be able to create a workspace above. At the same time, "zooming out" workspaces for moving windows as opposed to just changing workspaces, that Allan suggests, would be a nice feedback too. Outside of scope of this bug, perhaps.
Created attachment 294632 [details] [review] windowManager: Split out workspace insertion from thumbnails We will soon allow to insert a new workspace by other means than DND in between workspace thumbnails, so move the relevant code to a new windowManager method.
Created attachment 294633 [details] [review] windowManager: Don't shift OR windows when inserting a workspace We are not supposed to mess around with OR windows, so don't try to shift them to a different workspace. This fixes a warning with newer versions of mutter.
Created attachment 294634 [details] [review] windowManager: Update active workspace after inserting a new one New workspaces are inserted by shifting all windows on workspaces below the insertion position down. As a result, when the new workspace is inserted before the active one, we end up with the illusion of a workspace switch. Instead, activate the workspace on which the windows from the active one ended up.
Created attachment 294635 [details] [review] windowManager: Allow moving a window above the top workspace When using dynamic workspaces, a new workspace will be appended when moving a window down to the last (empty) workspace. It makes sense to extend the behavior in the opposite direction, and prepend a new workspace when moving a window up from the first workspace.
Review of attachment 294632 [details] [review]: seems to work fine despite the comment ::: js/ui/workspaceThumbnail.js @@ -815,3 @@ - }); - - this._spliceIndex = newWorkspaceIndex; shouldn't this line remain here?
Review of attachment 294633 [details] [review]: ok
Review of attachment 294634 [details] [review]: looks good
Review of attachment 294635 [details] [review]: ok
(In reply to comment #13) > - this._spliceIndex = newWorkspaceIndex; > > shouldn't this line remain here? Good catch - that was indeed not intentional, I added it back before pushing. Attachment 294632 [details] pushed as cc05d30 - windowManager: Split out workspace insertion from thumbnails Attachment 294633 [details] pushed as 67ec1e5 - windowManager: Don't shift OR windows when inserting a workspace Attachment 294634 [details] pushed as 0bfaa5c - windowManager: Update active workspace after inserting a new one Attachment 294635 [details] pushed as ce35d52 - windowManager: Allow moving a window above the top workspace
*** Bug 696350 has been marked as a duplicate of this bug. ***
One thing that doesn't seem to be working for me is the rule of only creating the first-1 workspace if the originating window some form the 1st workspace. Might be my dual head setup, but for me it gets created every time, even if I pull a window from a second workspace.
(In reply to Jakub Steiner from comment #19) > One thing that doesn't seem to be working for me is the rule of only > creating the first-1 workspace if the originating window some form the 1st > workspace. Might be my dual head setup, but for me it gets created every > time, even if I pull a window from a second workspace. I assume you mean second monitor? While the windows there are set to show on all workspaces, they still have a workspace ... As this is only tangentially related to this bug (the same happens when "moving" a window on the 2ndary monitor to the empty workspace at the end), I filed it as bug 746782.
I meant a window coming from somewhere else but the first workspace as described in the first comment/report: "The only negative point I could see here is that it may interfere with someone who wants to take a window from some workspace far down (ie: more than 2) and 'slam it to the top' by holding down Alt+Ctrl+Shift and pressing 'up' a bunch of times. Fitts' keyboard law, if you will. That could be dealt with by requiring the user to release and re-press Alt+Ctrl+Shift before a new workspace is created, in this case." When I do that, I create a workspace on top, rather than moving the window to the existing first workspace. Disregard my note on dualhead, I just disabled my secondary display and get the same behavior.