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 662581 - Do not switch to overview after closing the last window on a workspace
Do not switch to overview after closing the last window on a workspace
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: overview
3.2.x
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 659188 687266 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-10-24 06:21 UTC by Eugueny Kontsevoy
Modified: 2013-08-31 21:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
windowManager: Don't open overview after closing the last window on a workspace (1.85 KB, patch)
2013-08-30 00:15 UTC, Florian Müllner
committed Details | Review

Description Eugueny Kontsevoy 2011-10-24 06:21:39 UTC
I use virtual desktops a lot. Now they're called "workspaces". That's fine.
However, Gnome3 currently has the following bug:

When I close the last window in a workspace, it won't let me have an empty desktop. It immeidately switches to this crazy "find an app" mode.

Basically it means that every time I close a window, I need to follow that with "Esc" to close the popping up shell. That's crazy. I have things on my desktop. I have shortcuts I use to launch apps, why are you dropping me into this "search mode" like if I pressed "Super"? I didn't!

Please fix this - this bug is incredibly annoying, it makes me cautious about closing windows.
Comment 1 Eugueny Kontsevoy 2011-10-25 03:44:53 UTC
I am on Gnome 3.2.0 on Ubuntu 11.09 if that helps.
Thanks.
Comment 2 Milan Bouchet-Valat 2011-11-19 14:42:59 UTC
Indeed, I think it would make sense to keep the current workspace open when there are no windows on it, at least until the users moves to another workspace. That wouldn't break the dynamic workspaces management, but would make the UI more predictable, less error-prone for users, and make fans of static workspaces a little less unhappy. ;-)

Designers?
Comment 3 Milan Bouchet-Valat 2011-11-19 14:52:43 UTC
Sorry, please ignore my previous comment, I was confused about your request.

About your proposal, I think the problem comes from the fact that you have things on your desktop. The default is to have an empty background. In that case, everything you might want to do is available from the overview (in particular, your app shortcuts are in the dash).
Comment 4 Eugueny Kontsevoy 2011-11-28 02:48:37 UTC
Hold on, let me clarify by providing use cases:

As a starting point I have the following setup:

Workspace 1
-----------
  * Editor for a document
  * Terminal window

Workspace 2
-----------
  * Couple of browser windows (documentation, etc)

Workspace 3
-----------
  * Several windows with IRC chats

See? 3 workspaces for 3 different types of activity. And I have hotkeys for switching: Win+1, Win+2, Win+3. I configure those using gnome-settings/keyboard. You must agree with me that this is VERY common setup. 

The problem arises when I close the editor and terminal in the FIRST workspace. When this happens the workspace DISAPPEARS, and my 2nd workspace becomes 1st, 3rd becomes 2nd and everything basically is screwed now.

To fix this I always open a new terminal (or something) and start re-arranging windows again. This is insane! Why would Gnome kill my 1st workspace?! Why can't I have an EMPTY FIRST workspace? I don't understand what problem this automatic killing is solving, but it clearly defines the purpose of "Workspace N" hotkey which Gnome has.

Here's a proposal: 
Never destroy an empty workspace unless it's the LAST one in the list. Yes, it should be perfectly legal to have an empty workspace surrounded by non-empty ones. This is important because workspace have NUMBERS associated with HOT KEYS and having a _temorary_ empty workspace is very common - it happens when you close a window before opening another one.

Currently I am afraid to close windows in gnome3.
Comment 5 Eugueny Kontsevoy 2012-02-09 08:12:19 UTC
Bumping to blocker, this is quite crazy, I am surprised that Gnome 3.2 was even released in this shape.
Comment 6 Milan Bouchet-Valat 2012-02-09 09:14:53 UTC
Please don't raise the priority of your own bugs. It's up to developers or designers to choose what's the most important, not to people experiencing the problem (else, all issues would be marked as blockers). Anyway, bug priority is never used in the Shell.

If this problem really hurts you, you can install the static workspaces extension. For most people, the current behavior isn't that bad (although I agree we can probably make it better).
Comment 7 Florian Müllner 2013-06-13 22:29:29 UTC
I know Jakub agrees, but let's get some more design voices.
Comment 8 Allan Day 2013-08-29 00:52:20 UTC
I'm inclined to agree with the bug report. It feels surprising, and is likely to be contrary to a user's intention in some circumstances (like if you were planning to move to another workspace after closing the window).

I'd expect the blank workspace to be removed once it is a) empty b) is not focused, and c) not the last workspace in the series.
Comment 9 Allan Day 2013-08-29 00:53:30 UTC
*** Bug 659188 has been marked as a duplicate of this bug. ***
Comment 10 Allan Day 2013-08-29 22:53:27 UTC
*** Bug 687266 has been marked as a duplicate of this bug. ***
Comment 11 Florian Müllner 2013-08-30 00:15:41 UTC
Created attachment 253570 [details] [review]
windowManager: Don't open overview after closing the last window on a workspace

Activating the overview is fairly easy (hot corner, <super>), so doing it
automatically after closing the last window on a workspace does not safe
a lot of effort; it does result in a surprising context switch when the
user does not expect the behavior.
Comment 12 Florian Müllner 2013-08-30 00:17:51 UTC
(In reply to comment #8)
> I'd expect the blank workspace to be removed once it is a) empty b) is not
> focused, and c) not the last workspace in the series.

Currently only a) and c) apply - not sure b) is absolutely required, given that we will switch to the last (empty) workspace when the current workspace is removed ...
Comment 13 drago01 2013-08-31 21:34:24 UTC
Review of attachment 253570 [details] [review]:

s/safe/save/ in the commit message .. code looks good.
If it causes more problems and confusion then it solves / helps lets remove it.
Comment 14 Florian Müllner 2013-08-31 21:54:23 UTC
Attachment 253570 [details] pushed as 39afb58 - windowManager: Don't open overview after closing the last window on a workspace