(In reply to comment #0)
> In keyboard shortcuts there are only 4 workspace for which is possible to bind
> shortcut like Alt+F1, Alt+F2... If more workspace are added you can not set
> similar shortcuts.

It is possible to set up shortcuts for up to 12 workspaces, but (as you noticed) only 4 of them are exposed in the UI.
The rationale for limiting the number of exposed shortcuts was along the lines that
 (1) exposing *all* of those shortcuts would clutter the keyboard
     panel (in particular as there is also an equal number of 
     shortcuts to move a window to workspace n)
 (2) making the number of exposed shortcuts dependent on the
     number of workspaces used is confusing with dynamic workspaces
     (and making the visibility also depend on dynamic/static workspaces
      would have complicated gnome-control-center's keybinding parser
      further - only exposing a fixed number on the other hand has
      allowed for some simplification and cleanup there)
In the resulting design discussion, we decided on four shortcuts being a good compromise between not cluttering the shortcut panel and fitting most users' needs. Everyone who does use more workspaces can still assign additional shortcuts from the CLI:

  gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-5 '["<Super>5"]'

*** Bug 706271 has been marked as a duplicate of this bug. ***

Hi.

Following up the discussion in bug #706271, the following would be a better less limiting solution


Do not simply cut the keybinding shown for workspaces at 4, but rather display exactly so many, as the user have workspaces defined.


If I have 16, I probably did this on purpose and DO therefore want to see the bindings for all 16 workspaces, but if I have only 2 or perhaps even one... why showing the other 2 respectively 3.


@Andre, could you then please re-open this bug?!


Cheers,
Chris.

(In reply to comment #3)
> Do not simply cut the keybinding shown for workspaces at 4, but rather display
> exactly so many, as the user have workspaces defined.

It used to work like that, but with GNOME3's (default) dynamic workspaces, it doesn't make much sense to continue to do so - the number of displayed shortcuts just changes seemingly randomly.

We could re-introduce the feature only for the case where static workspaces are used, but considering the major cleanup in gnome-control-center code that went along with the change, I doubt the maintainers will be happy with introducing even uglier code (due to the additional condition) for a non-default configuration (e.g. that requires users to use gsettings/dconf-editor/tweak-tool) ...

Don't we support a configurable number of workspaces in Classic Mode?

Classic mode uses static workspaces by default, but doesn't expose the num-workspaces setting anywhere (but the aforementioned tools)

Well... I mostly applied this to classic mode, I once tried gnomeshell for a few days but since it broke more or less all of my usage scenarios I had to drop it again.
The "dynamic workspaces" actually being on of the major reasons... I know exactly how much workspaces I want to use and each has is designated meaning to... so I couldn't live with a system which tries to auto-magically guess what I want...

Anyway... I haven't noticed that the number of configurable workspaces was just another thing that got victim to GNOME's feature-removal-frenzy, just now that you've said it.
So in principle this gives just another bug report to bring that back... but it's like fighting windmills if the system get's apparently intentionally crippled.

To put it short: People want to configure their number of workspaces and to assign keybindings to all of them.

Cheers,
Chris.

Note that my point of comment #4 was meant to be this:
The proposed change is not a big deal on the mutter/gnome-shell side, it's just some additions to an xml file there. The burden is on gnome-control-center which parses the file - right now the format is a simple markup language, the requested feature would require to add conditionals to it (again, as this was how it used to work in GNOME2; but this time conditionals would be more complex, to support the additional static-workspaces condition (not to mention that the schema where this setting is found depends on the session mode used ...))

Well... I guess I cannot say much more as that it's probably the reason why a "control centre" exist... namely to control things...

I guess it's quite obvious that I have a problem with... let's say the road GNOME has chosen with respect to feature-richness and being usable for "power users"...
But I guess my usual argument "people should be able to control/configure their system"... won't change GNOME's mind.


So... yeah you may be right an it's some work for gnome-control-center to get this into... OTOH this should be a simple matter of setting some flags/options.. if that's already such a big problem,... upstream should wonder whether it hasn't set up a control-center-system that is too complex for the real world, especially if GNOME anyway tries to remove as much as options as possible.

(In reply to comment #9)
> Well... I guess I cannot say much more as that it's probably the reason why a
> "control centre" exist... namely to control things...

Though this is getting on a meta-level again (as many of your tickets in Bugzilla do) and out of scope for the specific request in this ticket:

Control Center exists to set preferences for functionality considered basic requirements that everybody has. GNOME will not expose every single potential setting of the system by cluttering the Control Center UI. 
Preferences for rather advanced needs (that only serve a small user group) go to gnome-tweak-tool or dconf which is an acceptable way for advanced users to tweak their advanced settings.