GNOME Bugzilla – Bug 646409
Allow dragging of workspaces to reorganize them
Last modified: 2021-07-05 14:23:59 UTC
It could be a duplicate, but I haven't found a bug about this yet... I love how workspaces work in gnome-shell, but there's really one missing thing for me: the ability to reorganize workspaces (with drag and drop in the overview, for example). Here's a use case: - I have 5 workspaces. Workspace 3 is where I have my code + terminal for development - I want to open devhelp and I want it to be in a new workspace, next to the workspace with my code - so I move to the new empty workspace (5th one), and launch devhelp - now I look for a way to swap workspaces 4 and 5. And there's no easy for this. Of course I can achieve this by moving windows around, but that's actually not trivial (if I move the last window of a workspace, the workspace gets removed so I have to start from scratch).
I just filed bug #648538, which seems to be a duplicate of this.
*** Bug 648538 has been marked as a duplicate of this bug. ***
*** Bug 649282 has been marked as a duplicate of this bug. ***
As I put in my 'dupe' (I was searching for 'desktop' instead of 'workspace' ;P) we should also have the ability to 'pin' workspaces. Just like the favorites bar. Then one could 'pin' say 4 workspaces, and they would NOT disappear when nothing is on them, and they would exist even on first login. This would allow for those of us who have very specific notions of how many workspaces we want and in what order can just pin them - sometimes you WANT an empty workspace to not go away, but to 'reserve' a space (eg. my 'root' window doesn't always have something running in it, but I want to keep it as my first workspace regardless). Dynamic workspaces would otherwise work the same, and we could drag them in between pinned workspaces as we see fit.
Preston, would this help you with your case? https://live.gnome.org/GnomeShell/Experiments/Design/Whiteboards/CustomCategories
David, Not so much - I'm more talking about being able to lay things out as you want, where you have the free space ready and waiting, and you even have to pass through that window on your 'way through' to others. I don't want to go tagging my applications for X purpose or Y purpose, especially when I may mix them (what would I tag Terminal?). But instead just having 'reserved' workspaces - or in this vernacular - 'pinned' or permanent workspaces as opposed to dynamic ones as currently exist. It's not as important a feature as re-ordering, but still one I would find extremely useful. Especially on startup (I can just switch to a perm workspace and start my app, instead of starting an app, then switching, rinse repeat, then having to re-order said workspaces). Preston.
Created attachment 187257 [details] [review] workspaceThumbnail: First draft at workspace reordering Allow a user to create a new workspace by dragging a window in the middle of two existing ones.
*** Bug 653304 has been marked as a duplicate of this bug. ***
*** Bug 655262 has been marked as a duplicate of this bug. ***
Jimmac: should we use the same drag and drop effect as in the dash, do you think?
aday: that sounds like a natural thing to do. But any sort of drop target highlight would do. We currently don't do anything even for dropping windows into workspaces.
Created attachment 195747 [details] [review] workspaceThumbnail: First draft at workspace reordering Allow a user to create a new workspace by dragging a window in the middle of two existing ones. Fix a minor JS warning -- thanks to jrb for making me remember about this patch. Unforunately, this still causes tons of "queue_relayout() not recommended" warnings, so I'm not sure exactly how to do better than this.
Created attachment 195816 [details] [review] workspaceThumbnail: Allow users to create new workspaces by dragging Allow a user to create a new workspace by dragging a window or a launcher in the middle of two existing ones. drag01 fixed the allocation errors. Thanks, drago01! Also, support for launchers.
Review of attachment 195816 [details] [review]: Looks good too me and seems to work fine. Just found some style issues and we need to find out what to do about the ui freeze (ask for an exception?). ::: js/ui/workspaceThumbnail.js @@ +21,3 @@ const SLIDE_ANIMATION_TIME = 0.2; +// See ThumbnailsBox.handleDragOver Probably better to add a comment explain what this is about instead of sending the reader from A to B to C ... @@ +510,3 @@ + this._dropPlaceholderPos = -1; + this._dropPlaceholder = new St.Bin({ style_class: 'dash-placeholder' }); The class name no longer matches ... not sure whether it is worth renaming. @@ +537,3 @@ + let workspace = -1; + for (let i = 0; i < this._thumbnails.length; i ++) { + let targetBase = (thumbHeight + spacing)*i; Missing whitespaces. @@ +580,3 @@ + let windows = global.get_window_actors().filter(function(win) { + if (isWindow) + return win.get_workspace() >= newWorkspaceIndex && win != source Missing semicolon.
(In reply to comment #13) > Created an attachment (id=195816) [details] [review] > workspaceThumbnail: Allow users to create new workspaces by dragging Oh and this title is misleading we already allow creating workspaces by dragging ... maybe "create at arbitrary positions" or something like that.
Created attachment 195818 [details] [review] workspaceThumbnail: Allow users to create workspaces at any position Allow a user to create a new workspace by dragging a window or a launcher in the middle of two existing ones. -- Should have fixed most of the review comments, and also an issue with the spacing
Review of attachment 195818 [details] [review]: Looks good to me, should be fine with rel-team / designer / doc team ok.
Any to have this merged in 3.2? This should fix one of the thing frustrating me most with the Shell.
*** Bug 661948 has been marked as a duplicate of this bug. ***
Created attachment 199164 [details] [review] workspaceThumbnail: Allow users to create workspaces at any position Allow a user to create a new workspace by dragging a window or a launcher in the middle of two existing ones. Don't rely on a silly gjs feature that turns metaWindow into meta_window.
Attachment 199164 [details] pushed as 703d2ea - workspaceThumbnail: Allow users to create workspaces at any position OK, I'm going to go ahead and push this. I think this is good enough to start with.
Oops. This doesn't allow you to reorder workspaces by dragging, so let's reopen.
Created attachment 211321 [details] [review] workspaceThumbnail: Allow dragging of workspaces to reorganize them Several problems with this patch: (1) A click on any space outside of the thumbnail itself, but inside the thumbnail box initiates a drag of that workspace. This will need to be fixed, but I need advice on how to determine if the cursor initiated a drag or if it was just a click (kinda like the _maybeStartDrag function in dnd.js) and where exactly drags should be initiated. (2) It works when dropping the workspace either on another workspace or a drop placeholder, but crashes if the drag is canceled. Crashes with: (gnome-shell:27789): St-ERROR **: st_widget_get_theme_node called on the widget [0x9c3cbe8 StWidget.workspace-thumbnail] which is not in the stage. [1] 27789 trace trap gnome-shell --replace (3) When dropping a workspace on to another (and moving all the windows) the space that used to be occupied by the moved workspace doesn't collapse until you do something with the thumbnails. It looks like maybe the background actor in the workspace is moving back to where it was and then it gets removed when it realizes there are no more windows on it, but the thumbnails don't get the signal to reflow. (4) It doesn't seem to release the grab once the drop is complete (the cursor remains in the move state). If you click and drag a window after you have moved the workspace though, the cursor behavior will return to normal, so somehow I'm not resetting the cursor/releasing the grab.
Review of attachment 211321 [details] [review]: The patch does not seem to have any effect here ... i.e I can't drag any workspaces with it applied. Also how is this supposed to interact with clicks from a user pov? Should we have a modifier key for it? As for the bugs you listed I couldn't obviously reproduce them as the patch does not seem to do anything here (other then printing out debug prints). ::: js/ui/workspaceThumbnail.js @@ +221,3 @@ + _onDragBegin: function(draggable, time) { + this.inDrag = true; + log('Workspace drag begin, inDrag: ' + this.inDrag); Remove the debug prints. @@ +522,3 @@ + + for (let i = 0; i < numWindows; i++) { + let metaWindow = source._allWindows[0]; This makes no sense ... shouldn't that be _allWindows[i] rather then 0? @@ +619,3 @@ + + for (let i = 0; i < this._thumbnails.length; i++) { + let thumbnail = this._thumbnails[i] Missing semicolon. @@ +621,3 @@ + let thumbnail = this._thumbnails[i] + let [w, h] = thumbnail.actor.get_transformed_size(); + log('onButtonPress (thumbnail) size: ' + w + ' ' + h + ' actor: ' + thumbnail.actor.x + ' ' + thumbnail.actor.y); Remove the debug print here as well. @@ +623,3 @@ + log('onButtonPress (thumbnail) size: ' + w + ' ' + h + ' actor: ' + thumbnail.actor.x + ' ' + thumbnail.actor.y); + if (y >= thumbnail.actor.y && y <= thumbnail.actor.y + h && (x > thumbnail.actor.x + w || x < thumbnail.actor.x)) { + thumbnail._draggable.startDrag(stageX, stageY, event.time); You seem to be trying to get the actor at a specific position ... instead of the loop you can just pick. i.e let foo = global.stage.get_actor_at_pos (Clutter.PickMode.REACTIVE, x, y) @@ +711,3 @@ let length = this._thumbnails.length; + // TODO: should we show the drop placeholders around the dragging workspace? + // Since dropping it on them wouldn't actually (visually) change anything. Should get some input from the designers about this. @@ +817,3 @@ + + for (let i = 0; i < numWindows; i++) { + let metaWindow = workspaceWindows[0]; The index is wrong here as well ... you want i not 0.
Created attachment 211665 [details] [review] workspaceThumbnail: Allow dragging of workspaces to reorganize them With the patch applied you should be able to initiate a drag with a click anywhere outside the thumbnail itself, but between the top and bottom of the thumbnail (inside the thumbnail container of course). Kinda confusing to explain, but the tiny space of the thumbnail container on either side of the thumbnail are areas that should initiate a drag. Definitely not final design. Sorry about the debug stuff, thought I got them all. Removed now. The reason the index is 0 and not i is because as windows are removed, the other windows shift down the array. So if we grab the first item in the array every time, we will be actually be iterating through all the windows. The reason I didn't try picks was due to the discussion on Bug 643319 and because I was unsure how dragging is supposed to be handled. I imagine any drag on the background actor of the workspace thumbnail or within the thumbnails horizontal slice of the thumbnail container should initiate a workspace drag, but that doesn't seem like a great solution. The drag area is going to be pretty small, particularly with full screen windows. This needs designer input as well.
(In reply to comment #25) > Created an attachment (id=211665) [details] [review] > workspaceThumbnail: Allow dragging of workspaces to reorganize them (More of a question to Adel: what's the benefit of manualMode here?) > With the patch applied you should be able to initiate a drag with a click > anywhere outside the thumbnail itself, but between the top and bottom of the > thumbnail (inside the thumbnail container of course). Kinda confusing to > explain, but the tiny space of the thumbnail container on either side of the > thumbnail are areas that should initiate a drag. Definitely not final design. What about the background actor? > The reason the index is 0 and not i is because as windows are removed, the > other > windows shift down the array. So if we grab the first item in the array every > time, we will be actually be iterating through all the windows. That's true for one of the loops (the source._allWindows) case, but not the other, as we make a copy of the list when it gets handed to JS. And in the first case, you really should either use a while loop or call forEach: while (source._allWindows.length > 0) { let window = source._allWindows[0]; window.change_workspace_by_index(...); } or: source._allWindows.forEach(function(window) { window.change_workspace_by_index(...); });
(In reply to comment #26) > (More of a question to Adel: what's the benefit of manualMode here?) Just to mention, without manualMode (and the thumbnail still reactive), a click initiates a drag on the window clicked and a drag anywhere will drag the whole workspace. So it breaks the current operation where a drag on a window will start a drag of that window and a click anywhere on the thumbnail will switch to that workspace. And manualMode nor reactive are strictly needed on the thumbnail currently since the drag is being triggered directly, but that may change depending on how dragging is to be triggered in the end. > What about the background actor? Do you mean, does a drag on the background actor start a workspace drag currently? No. Should it? Probably, but for workspaces with fullscreen apps the drag area will still be small. > That's true for one of the loops (the source._allWindows) case, but not the > other, as we make a copy of the list when it gets handed to JS. And in the > first case, you really should either use a while loop or call forEach: > > while (source._allWindows.length > 0) { > let window = source._allWindows[0]; > window.change_workspace_by_index(...); > } > > or: > > source._allWindows.forEach(function(window) { > window.change_workspace_by_index(...); > }); I still get the dynamic changes on workspaceWindows since source.getWindows() is just returning a reference to _allWindows. Is this an improper way to access private variables? Or is this not what you were talking about? Those methods are much cleaner. Will make the changes.
(In reply to comment #27) > I still get the dynamic changes on workspaceWindows since source.getWindows() > is just returning a reference to _allWindows. Is this an improper way to access > private variables? Or is this not what you were talking about? Whoops, my fault, I didn't realize what was happening here.
Created attachment 212105 [details] [review] workspaceThumbnail: Allow dragging of workspaces to reorganize them Switch to while loops.
Can I throw in once more the idea to use a modifier for dragging workspaces, say Alt ? That would avoid interference with window dragging, and solve the issue that many interesting workspaces are covered in windows, and thus there's no free background to start a drag on.
(In reply to comment #30) > Can I throw in once more the idea to use a modifier for dragging workspaces, > say Alt ? That would avoid interference with window dragging, and solve the > issue that many interesting workspaces are covered in windows, and thus there's > no free background to start a drag on. I don't think it makes sense to allow dragging individual windows from the workspace thumbnails. They're either too small, or they're maximized and obscure the whole workspace. Besides, the workspace is the primary object of interaction in this case.
(In reply to comment #31) > I don't think it makes sense to allow dragging individual windows from the > workspace thumbnails. I beg to disagree. This is one of the most frequent things I do when I'm on the activity overview.
(In reply to comment #32) > (In reply to comment #31) > > I don't think it makes sense to allow dragging individual windows from the > > workspace thumbnails. > > I beg to disagree. This is one of the most frequent things I do when I'm on the > activity overview. Yeah I use this pretty often as well and see more use to it then dragging the workspace itself.
I'll pitch in my own experience; dragging windows around from the bottom-most workspace to the top-most is something that reliably happens to me during a work session.
From my experience what's utterly annoying with current workspace behaviour: 1) After an upgrade of firefox, it has a "restart" button appearing, click that button and firefox closes, the workspace closes, and restart on last workspace. So need to DnD the window to move it again in the workspace I want. 2) After each suspend, xchat-gnome does not reconnect, so I have to close it and restart it. But closing it also closes the workspace, so again I have to DnD the new window to the position I want. I'm now used to hit ctr-alt-t to open a terminal, restart x-g, close the terminal, just to keep that damned workspace open. Otoh, DnD the window between workspaces to insert a new one makes the experience less bad already. Since I usually have only one window per workspace, allowing the DnD workspaces won't help my personal usage much. But I can understand lots of people would need that. So in my particular usage, more than DnD workspaces what I would like is being able to define a minimal number of workspaces. So workspaces [1,x] never closes, and [x+1, -] open/close automatically as now.
This feels like a bug that people have grown accustomed to. Windows are the primary object in the window picker, workspaces are the primary objects in the workspace switcher. Let's not get the two mixed up. It is *really* weird to interact with the content of a thumbnail, and there are interaction issues with allowing that. Also, we already have a way of moving a window to a different workspace.
(In reply to comment #35) > From my experience what's utterly annoying with current workspace behaviour: > > 1) After an upgrade of firefox, it has a "restart" button appearing, click that > button and firefox closes, the workspace closes, and restart on last workspace. > So need to DnD the window to move it again in the workspace I want. > > 2) After each suspend, xchat-gnome does not reconnect, so I have to close it > and restart it. But closing it also closes the workspace, so again I have to > DnD the new window to the position I want. I'm now used to hit ctr-alt-t to > open a terminal, restart x-g, close the terminal, just to keep that damned > workspace open. > Wouldn't drag'n'drop TO workspace switcher be sufficient for your usecase?
Where do we stand on this ? From Allans last comment, it seems the proposal here is to change the primary action to dragging workspaces, not windows, and make dragging of windows a secondary action (if at all) ?
I'm also interested in being able to both drag workspaces and windows to workspaces. If I understood this correctly, the proposal is: 1) Drag workspaces (and not windows) in the workspace switcher 2) Keep allowing the user to drag windows from the window picker to a workspace in the workspace switcher. I would also add that Matthias idea of adding a key modifier to allow dragging of windows from the workspace switcher would be useful to reorganize windows without switching workspaces back and forth. Alt is currently not used as far as I know. Arnoques (an interested user)
(In reply to comment #38) > Where do we stand on this ? From Allans last comment, it seems the proposal > here is to change the primary action to dragging workspaces, not windows, and > make dragging of windows a secondary action (if at all) ? Being able to drag windows from the workspace thumbnails seems a bit odd to me, but I'd be OK with having it as a secondary behaviour (through the Alt modifier key) should there be a demand for that.
(In reply to comment #40) > (In reply to comment #38) > > Where do we stand on this ? From Allans last comment, it seems the proposal > > here is to change the primary action to dragging workspaces, not windows, and > > make dragging of windows a secondary action (if at all) ? > > Being able to drag windows from the workspace thumbnails seems a bit odd to me, > but I'd be OK with having it as a secondary behaviour (through the Alt modifier > key) should there be a demand for that. I guess all that is missing here now is a patch that does this...
I have an additional suggestion: Normally CTRL+ALT+UP / DOWN switches up and down between the workspaces (in both overlay / non-overlay), and in non-overlay CTRL+SHIFT+ALT+UP / DOWN moves the currently selected window up and down between the workspaces. However CTRL+SHIFT+ALT+UP / DOWN does nothing in the overlay and it wouldn't make sense to move a window as none are selected. I propose that this shortcut is used to swap the current workspace with the adjacent workspace above or below. This would provide a quick keyboard alternative to switching workspaces and the shortcut would now have a similar behaviour as it had before in non-overlay but now applied to the overlay. Also in regards to the mouse: Another way to rearrange workspaces in the overlay with the current behaviour could be to click-and-hold on a workspace for a couple of seconds, THEN the workspace becomes moveable (or if the behaviour is swapped then the window becomes moveable), this would provide a mouse only way of doing this which would also be touchscreen/tablet friendly. However with this method there might need to be some sort of visual feedback to indicate what is actually happening.
(In reply to comment #42) > in non-overlay CTRL+SHIFT+ALT+UP / DOWN moves the currently selected window > up and down between the workspaces. > > However CTRL+SHIFT+ALT+UP / DOWN does nothing in the overlay and it wouldn't > make sense to move a window as none are selected. Agreed. > I propose that this shortcut is used to swap the current workspace with the > adjacent workspace above or below. Having a shortcut perform different actions based on context is likely to be confusing. Also, I don't see why a swap-workspace action should be restricted to the overview.
*** Bug 694979 has been marked as a duplicate of this bug. ***
IMHO Alan is right (comment #42). Click and hold should allow for moving workspaces. It seems to be a most reasonable solution. Unity, Metro and probably some other UIs do that too to allow dragging stuff (dock items and start screen tiles respectively). This means some users might be already familiar with it. Dragging by clicking on the background might be used as additional way, but this needs some designer input and some testing on users - it might be confusing. (Some users may assume that if there is one way to do it - drag by clicking on background - then it's the only way. So relatively high discoverability of drag by background in this case might lower the discoverability of click and hold.)
Created attachment 250574 [details] [review] Allow for rearranging workspaces from the workspace dock This patch allows for workspaces on the workspace dock to be rearranged. One can long-press on a workspace or ctrl-drag to start rearranging. This patch works pretty well and enables all of the functionality needed for rearranging workspaces, however I would like some input on finishing it up: 1. I currently have to do a few things to get the clutterClickAction and the button-press and button-release signals to not interfere. Is there some way I don't have to do this? 2. When starting a drag, the thumbnail changes position to another part of the screen. Is this a bug in the DND code, or do I have to re-position the thumbnail back to its original place? 3. The code for enabling drop after the last workspace is kind of tacked on. If there is a better way to do this, I'd like to know. 4. The placeholder doesn't show up if one wants to drop a thumbnail after the last workspace. I don't want to have to mess with all the placeholder code, but I don't see a good way to make it show up. 5. Do I need more/fewer/clearer comments/methods/variables in places? This code is basically there (functionality wise), it might need just some refinement. I'd like some suggestions.
(In reply to comment #46) Hey Bradley, Thanks for the patch! Not a review, but I have some older work that does workspace dragging with window dragging when ALT is pressed: https://gitorious.org/gnome-doshitan/gnome-shell/commits/wip/drag-workspaces I take a different route than you, but maybe you can find something useful in there. Haven't had a chance to work on it in the past couple of months though, so no guarantees (^_^).
*** Bug 725718 has been marked as a duplicate of this bug. ***
*** Bug 736309 has been marked as a duplicate of this bug. ***
Hi, is there any progress made on this issue? It seems nothing has happened for more than a year.
No progress, otherwise it would be listed here. "Target Milestone" got set to 3.16 though (which does not necessarily mean that somebody works on this).
No progress I assume? From the patch it looks like there is no mechanism in mutter to actually change the order of the workspaces? So to properly rearrange workspaces you'd have to change to workspace of all windows involved, change the workspace labels and update any custom functionality that associate with workspace identities? (wallpaper per workspace etc.) That isn't possible to do in a fully general way as any extension could add workspace-identity-dependent functionality?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.