GNOME Bugzilla – Bug 572312
Allow the removal of any empty workspace
Last modified: 2010-02-25 19:52:21 UTC
It's kind of confusing (for me at least) to be able to remove only the last added activity (if it's empty). That means that if I have 10 activities of which 7 are empty, but the last one has an open window, I can't remove any of the empty activities. Therefore, I think that any empty activity should have a "Remove activity" button. Removing an activity near the edge of the screen would slide it off just like now, and removing an activity in the center (surrounded by other activities) would make it shrink until it disappears and other activities would then rearrange to fill the hole.
(In reply to comment #0) > Removing an activity near the edge of the screen would slide it off just like > now, and removing an activity in the center (surrounded by other activities) > would make it shrink until it disappears and other activities would then > rearrange to fill the hole. My theory when I did the workspaces code was that workspaces would never change their positions relative to each other, so that you always know where each one is. (In GNOME-ese, "it's spatial".) I'd thought about making it possible to delete the last N workspaces all at once if they're all empty. (Each one would have a (-) button that would also delete all of the workspaces after it.) > That means that if I have 10 activities of which 7 are empty, but the last one > has an open window, I can't remove any of the empty activities. True, but... would you really end up with that scenario?
I think there's an additional bug here. Try the following: Create six workspaces. Put a window in 1, 2 and 5. 6 will have a (-) in it. Remove 6 (press the -). 1, 2 and 5 are still populated. I agree with Jay Bee that it feels very odd that I can't remove 3 and 4: let's say that I was making some calls with skype in 3, but I've finished now, so I want to remove what is now (from my point of view) a "dead" workspace. Why should I have to move the window from 5 to 3 to be able to remove 3 (having first removed 4)? (Hopefully this addresses Dan's "True, but..." question. Well, I'll move the window from 5 to 3 anyway. However, I find that I can't remove 5 after all! Even if I add 6 again, there's now no way of removing 3 or 4. It seems that once a workspace has been marked as "active", it can't be removed. Seems like a bug to me, unless I've missed the philosophy. I'm coming to this as a newb to gnome-shell, though, and it does feel odd.
Hmm - I'm even more confused! It seems my naming of the workspaces might be "wrong"... I had two rows, which I named thus: 1,2,3 4,5,6 It appears that if I have windows in 1,2 and 5, I can remove 6, then 3, then move the window to 4 and remove 5. I'm going to try to create a movie to show what I did, and attach it. ---- I've tried to do this, but can't make the screencast work. I'll report that as a bug.
(In reply to comment #3) > Hmm - I'm even more confused! It seems my naming of the workspaces might be > "wrong"... I had two rows, which I named thus: > > 1,2,3 > 4,5,6 > > It appears that if I have windows in 1,2 and 5, I can remove 6, then 3, then > move the window to 4 and remove 5. That's correct, because the workspaces are actually numbered 1 2 5 3 4 6 because that's the order they were created in, because we don't want to rearrange or renumber them after creating them.
I think that's something we may want to fix at some point. When activities are here, I'd like to allow users to start an activity with a new workspace, and eventually to remove that workspace when they're done, even if there are used workspaces after it. I don't know if the fact that there are no gaps in indexes is really essential to Metacity's code, but at least we could remove the workspace without freeing its index. I mean: reserve its index so that no numbers change, but remove the workspace anyway. Th
I've seen at least two videos[1] on the net where people moved their mouse pointer to remove an empty workspace only to find that the "minus" appeared on a different workspace or didn't appear at all, it really shows how unintuitive this behaviour is. New or inexperienced users will probably be baffled. [1] First video - Fudcon @ (11:35) http://alt.fedoraproject.org/pub/alt/videos/2009/FUDConF11/fudcon-f11-rm345-session4.ogg Second video - youtube @ (00:22) http://www.youtube.com/watch?v=kcpndKUx4pc
That's my experience. I'd like to be able to remove any unused workspace: it seems like the obvious thing to be able to do: I'd like to see this, as per Milan's suggestion.
One step further: has anyone thought about not allowing more than one _empty_ activity? IMHO it would be very nice if unused activities were terminated automatically. I mean, adding lots of workspaces looks funny in demo videos but do they actually serve a purpose? I don't think so. The only use I see is creating a number of activity screens in advance to quicky start many apps via d&d after that. The same could be done by d&d to the (+) button (which is a feature tracked in another bug). The system should clean up after the user automatically whenever possible. It would also help to differentiate classical workspaces from activities.
Perhaps it's worth trying some simple algorithm that will move the remaining workspaces to the left and up when a workspace is removed, but won't move the workspaces around so that they have to cross each other to get to their new position.
(In reply to comment #9) > Perhaps it's worth trying some simple algorithm that will move the remaining > workspaces to the left and up when a workspace is removed, but won't move the > workspaces around so that they have to cross each other to get to their new > position. (several ASCII-art diagrams later) that will work except when removing a workspace causes the grid to be resized; if you have a grid with only one workspace in its rightmost column, and you delete a workspace that isn't in the first row, then you need to move the "orphan" workspace down to the row with the deleted workspace, and then you can move workspaces left to fill the hole. Likewise, if you have a grid with only one workspace in its bottom row, and delete a workspace that isn't in the first column, then you need to move the orphan workspace right.
A solution that would both enable users to close empty workspaces as they wished and keep the numbering structure is to always close the last workspace just as the system is set up now. And if another workspace than the last one is requested to close the applications running on higher numbered workspaces should be moved one number down and the workspace with the highest number will be closed. Example: We have workspaces 1 3 and 4 populated with applications and workspace 2 is empty. The user clicks that the empty workspace number 2 should be closed and gets visual response from Gnome-shell that it so is done. But underneath the visual clutter interface what has happened is that all applications on workspace 3 has been moved to workspace 2 and all applications on workspace 4 has been moved to workspace 3 meanwhile workspace 4 is closed off. Graphicly workspace nr 2 shrinks and disappears or flows off the screen meanwhile workspace number 3 and number 4 is moved along the grid to take the beforecomming workspaces place.
Sorry, I haven't caught up on all the comments yet but wanted to mention that I think it is an open question whether we should allow multiple empty workspaces at all.
Created attachment 146959 [details] [review] Patch for this bug
I think that it'd be best to allow user to have numerous empty workspaces and to allow him to close any of them also. (or even better - make both things tunable) Here's why: If someone prefer not to reorder workspaces, then he just would not close the workspace in the middle. If someone prefer to have only one empty workspace, then he would not open a new one when he already have an empty workspace. P.S. Computer should not restrict users to do what seems obvious to a user. :) (Try to get out of the way of a user. Remember, yeah ? :) )
This seems fixed now, since the linear view landed it is possible to remove non empty workspaces in both linear and mosaic view.
(In reply to comment #15) > This seems fixed now, since the linear view landed it is possible to remove non > empty workspaces in both linear and mosaic view. you can now remove any workspace in the linear view, and you can always remove the last workspace in the grid view. given that there are no longer per-workspace remove buttons, it's not clear how you could remove any other workspace in the grid view. so yeah, this is is somewhere between FIXED and OBSOLETE.