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 646409 - Allow dragging of workspaces to reorganize them
Allow dragging of workspaces to reorganize them
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
touch
: 648538 649282 653304 655262 661948 694979 725718 736309 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-04-01 06:17 UTC by Vincent Untz
Modified: 2021-07-05 14:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
workspaceThumbnail: First draft at workspace reordering (7.17 KB, patch)
2011-05-05 02:50 UTC, Jasper St. Pierre (not reading bugmail)
none Details | Review
workspaceThumbnail: First draft at workspace reordering (7.20 KB, patch)
2011-09-06 05:15 UTC, Jasper St. Pierre (not reading bugmail)
none Details | Review
workspaceThumbnail: Allow users to create new workspaces by dragging (7.91 KB, patch)
2011-09-06 17:22 UTC, Jasper St. Pierre (not reading bugmail)
reviewed Details | Review
workspaceThumbnail: Allow users to create workspaces at any position (8.94 KB, patch)
2011-09-06 18:16 UTC, Jasper St. Pierre (not reading bugmail)
accepted-commit_after_freeze Details | Review
workspaceThumbnail: Allow users to create workspaces at any position (8.92 KB, patch)
2011-10-17 00:50 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
workspaceThumbnail: Allow dragging of workspaces to reorganize them (12.47 KB, patch)
2012-04-04 19:15 UTC, Tanner Doshier
needs-work Details | Review
workspaceThumbnail: Allow dragging of workspaces to reorganize them (12.63 KB, patch)
2012-04-09 18:50 UTC, Tanner Doshier
none Details | Review
workspaceThumbnail: Allow dragging of workspaces to reorganize them (12.52 KB, patch)
2012-04-15 23:24 UTC, Tanner Doshier
none Details | Review
Allow for rearranging workspaces from the workspace dock (14.68 KB, patch)
2013-08-01 01:06 UTC, Bradley Pankow
none Details | Review

Description Vincent Untz 2011-04-01 06:17:51 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).
Comment 1 David Prieto 2011-04-24 02:00:20 UTC
I just filed bug #648538, which seems to be a duplicate of this.
Comment 2 David Prieto 2011-04-24 02:01:29 UTC
*** Bug 648538 has been marked as a duplicate of this bug. ***
Comment 3 Owen Taylor 2011-05-03 14:34:42 UTC
*** Bug 649282 has been marked as a duplicate of this bug. ***
Comment 4 Preston A. Elder 2011-05-03 14:47:39 UTC
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.
Comment 5 David Prieto 2011-05-03 19:51:02 UTC
Preston, would this help you with your case? https://live.gnome.org/GnomeShell/Experiments/Design/Whiteboards/CustomCategories
Comment 6 Preston A. Elder 2011-05-04 00:56:47 UTC
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.
Comment 7 Jasper St. Pierre (not reading bugmail) 2011-05-05 02:50:19 UTC
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.
Comment 8 Rui Matos 2011-06-24 03:11:23 UTC
*** Bug 653304 has been marked as a duplicate of this bug. ***
Comment 9 Jasper St. Pierre (not reading bugmail) 2011-07-25 14:23:04 UTC
*** Bug 655262 has been marked as a duplicate of this bug. ***
Comment 10 Allan Day 2011-07-25 14:27:09 UTC
Jimmac: should we use the same drag and drop effect as in the dash, do you think?
Comment 11 Jakub Steiner 2011-07-25 14:36:42 UTC
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.
Comment 12 Jasper St. Pierre (not reading bugmail) 2011-09-06 05:15:01 UTC
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.
Comment 13 Jasper St. Pierre (not reading bugmail) 2011-09-06 17:22:06 UTC
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.
Comment 14 drago01 2011-09-06 17:31:48 UTC
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.
Comment 15 drago01 2011-09-06 17:33:52 UTC
(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.
Comment 16 Jasper St. Pierre (not reading bugmail) 2011-09-06 18:16:40 UTC
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
Comment 17 drago01 2011-09-06 18:35:56 UTC
Review of attachment 195818 [details] [review]:

Looks good to me, should be fine with rel-team / designer / doc team ok.
Comment 18 Guillaume Desmottes 2011-09-09 13:57:11 UTC
Any to have this merged in 3.2? This should fix one of the thing frustrating me most with the Shell.
Comment 19 Rui Matos 2011-10-16 23:29:38 UTC
*** Bug 661948 has been marked as a duplicate of this bug. ***
Comment 20 Jasper St. Pierre (not reading bugmail) 2011-10-17 00:50:46 UTC
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.
Comment 21 Jasper St. Pierre (not reading bugmail) 2011-11-07 19:37:12 UTC
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.
Comment 22 Jasper St. Pierre (not reading bugmail) 2011-11-07 19:38:21 UTC
Oops. This doesn't allow you to reorder workspaces by dragging, so let's reopen.
Comment 23 Tanner Doshier 2012-04-04 19:15:50 UTC
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.
Comment 24 drago01 2012-04-09 17:57:41 UTC
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.
Comment 25 Tanner Doshier 2012-04-09 18:50:37 UTC
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.
Comment 26 Jasper St. Pierre (not reading bugmail) 2012-04-10 02:10:11 UTC
(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(...);
    });
Comment 27 Tanner Doshier 2012-04-10 04:23:18 UTC
(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.
Comment 28 Jasper St. Pierre (not reading bugmail) 2012-04-10 05:01:59 UTC
(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.
Comment 29 Tanner Doshier 2012-04-15 23:24:03 UTC
Created attachment 212105 [details] [review]
workspaceThumbnail: Allow dragging of workspaces to reorganize them

Switch to while loops.
Comment 30 Matthias Clasen 2012-07-03 00:39:46 UTC
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.
Comment 31 Allan Day 2012-07-03 13:25:35 UTC
(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.
Comment 32 Vincent Untz 2012-07-03 13:37:25 UTC
(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.
Comment 33 drago01 2012-07-03 13:39:35 UTC
(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.
Comment 34 Emmanuele Bassi (:ebassi) 2012-07-03 13:54:02 UTC
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.
Comment 35 Xavier Claessens 2012-07-03 14:04:06 UTC
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.
Comment 36 Allan Day 2012-07-03 14:08:46 UTC
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.
Comment 37 Maciej (Matthew) Piechotka 2012-07-07 04:09:31 UTC
(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?
Comment 38 Matthias Clasen 2012-08-27 14:59:04 UTC
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) ?
Comment 39 arnoques 2012-08-27 16:26:03 UTC
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)
Comment 40 Allan Day 2012-08-28 08:31:35 UTC
(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.
Comment 41 Matthias Clasen 2012-09-13 18:05:58 UTC
(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...
Comment 42 Alan Chambers 2012-10-31 10:55:55 UTC
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.
Comment 43 Florian Müllner 2012-10-31 13:53:49 UTC
(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.
Comment 44 Giovanni Campagna 2013-03-02 13:53:28 UTC
*** Bug 694979 has been marked as a duplicate of this bug. ***
Comment 45 Daniel Preston 2013-05-08 12:15:14 UTC
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.)
Comment 46 Bradley Pankow 2013-08-01 01:06:16 UTC
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.
Comment 47 Tanner Doshier 2013-08-01 14:59:35 UTC
(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 (^_^).
Comment 48 Florian Müllner 2014-03-05 13:38:15 UTC
*** Bug 725718 has been marked as a duplicate of this bug. ***
Comment 49 Florian Müllner 2014-09-09 12:13:42 UTC
*** Bug 736309 has been marked as a duplicate of this bug. ***
Comment 50 Eddie 2014-11-06 13:07:05 UTC
Hi, is there any progress made on this issue? It seems nothing has happened for more than a year.
Comment 51 André Klapper 2014-11-06 13:44:38 UTC
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).
Comment 52 olejorgenb 2017-09-24 10:36:14 UTC
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?
Comment 53 GNOME Infrastructure Team 2021-07-05 14:23:59 UTC
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.