GNOME Bugzilla – Bug 606460
need to decide the max number of workspaces allowed
Last modified: 2010-01-20 19:38:19 UTC
GNOME Shell seems to support adding an arbitrary number of workspaces. This is bad, because Mutter doesn't; Mutter has the fixed-size array workspace_names[MAX_REASONABLE_WORKSPACES], where MAX_REASONABLE_WORKSPACES is 36. This can cause a crash. In GNOME Shell, add loads (at least 36) of workspaces. Click on any of the workspaces. Now attempt to switch workspace using the keyboard combo Ctrl-Alt-{Left,Right}; Mutter crashes. This can't happen in GNOME 2.x, because you can't set there to be more than 36 workspace. Here are the debug messages: Window manager warning: Log level 8: meta_prefs_get_workspace_name: assertion `i >= 0 && i < MAX_REASONABLE_WORKSPACES' failed ** mutter:ERROR:core/screen.c:1669:meta_screen_workspace_popup_create: assertion failed: (entries[i].title != NULL) What happens is meta_screen_popup_create calls meta_prefs_get_workspace_name (via meta_workspace_get_name) to get the name of a high-index workspace. _get_workspace_name returns NULL and trips the warning because of the call g_return_val_if_fail (i >= 0 && i < MAX_REASONABLE_WORKSPACES, NULL);. Because Mutter doesn't know the name of the workspace, _popup_create fails the above assertion. Obviously one solution would be to limit the number of workspaces you can create in gnome-shell. It's probably not useful, but here's a backtrace just before the crash: Breakpoint 1, meta_screen_workspace_popup_create (screen=<value optimized out>, initial_selection=<value optimized out>) at core/screen.c:1669 (gdb) bt
+ Trace 219971
ok, if metacity actually enforces some maximum number of workspaces, then we need to decide the maximum gnome-shell will support
Well, if it's *desirable* to support an arbitrary number of workspaces, I think I could come up the patch for Mutter. AFAICT all that needs done is for workspace_names to become a GPtrArray. Metacity's schema.in says the number was capped for `performance reasons', which is understandable. Should I go ahead? Or would you rather cap?
Who needs more than 36 workspaces, anyway? Just pick MAX_REASONABLE_WORKSPACES for the shell too.
I think I agree with Dan here that if we are going to put a number in and not just say "if you keep on clicking the + button, you get what you deserve", we should put a number in that makes sense from a user interface perspective. I'd suggest 16 - the UI really isn't designed for more than that. (If somebody makes a patch, the comment above the constant should mention the hard limit of Metacity's MAX_REASONABLE_WORKSPACES.) I don't see any reason for a Mutter patch - the current limit is more than anybody could really want.
Created attachment 151702 [details] [review] [overview] disable the AddWorkspaceButton if there are >= 16 workspaces
Created attachment 151703 [details] [review] [dnd] Don't allow dropping on non-reactive actors
Review of attachment 151702 [details] [review]: Looks good
Review of attachment 151703 [details] [review]: Looks good
Attachment 151702 [details] pushed as a50d64e - [overview] disable the AddWorkspaceButton if there are >= 16 workspaces
Created attachment 151867 [details] [review] [dnd] revert the change to only allow dropping on reactive actors Workspace.actor is non-reactive, and there's probably some good reason for this. So just have the add workspace button check its own reactivity.
Review of attachment 151867 [details] [review]: Looks good!