Bug 826024

Summary: Missing keyboard shortcut for switch to workspace 5+
Product: [Fedora] Fedora Reporter: Jes Sorensen <Jes.Sorensen>
Component: gnome-shellAssignee: Florian Müllner <fmuellner>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 19CC: a9016009, dap78, emcnabb, evplus.si, jbastian, jh.redhat, maxamillion, otaylor, pcfe, petr.danecek, pgp, samkraju, walters
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-17 09:16:11 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
script to tweak workspaces and hotkeys none

Description Jes Sorensen 2012-05-29 08:07:29 EDT
Description of problem:
The version of gnome-shell in Fedora 17 no longer offers switch to workspace
X, with X being the number of workspaces in use.

I rely on having 6 workspaces in my setup which I jump between using Alt+F[1-6].

Using the bindings for switch to workspace above/below/left/right is
not an alternative. Like most developers I have apps/tasks statically
assigned to specific workspaces and rely on direct jumps to all of them.

Please fix asap - this is a regression from Fedora 16.


Version-Release number of selected component (if applicable):


How reproducible:
Every time

Steps to Reproduce:
1. Install Fedora 17
2. Try to assign a keybinding to 'Switch to workspace X' X>=5
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Roland Pallai 2012-06-03 19:39:58 EDT
Jes,


I agree with you, it's a disappointing regression. Although there's a simple workaround now - use Autokey (http://code.google.com/p/autokey/).


The script for workspace switching is 1 line in Autokey:

 window.switch_desktop(N)

where N = 4..Z (4 means your 5th workspace).
Comment 2 Jes Sorensen 2012-06-04 05:18:03 EDT
Pallai,

Thanks, it shows up one can also do it manually using the magic dconf
tool setting undocumented variables, like this:

dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-5 [\'\<Alt\>F5\']

and to move windows to those workspaces:

dconf write /org/gnome/desktop/wm/keybindings/move-to-workspace-6 [\'\<Primary\>F6\']

Whoever wrote the keybindings tool just didn't seem to think anybody should
need workspaces > 4 :(

Hopefully this will get fixed in the next update, it's a *really* irritating
limitation added for no reason.

Jes
Comment 3 Florian Müllner 2012-06-05 12:17:46 EDT
(In reply to comment #2)
> Whoever wrote the keybindings tool just didn't seem to think anybody should
> need workspaces > 4 :(

It is a bit more complicated than that :)

The way it used to work was to show one "switch to workspace <n>" keybinding in System Settings for each workspace. This was fine as long as the number of workspaces was a user preference, but not a good fit for GNOME 3's dynamic model - basically users had to make sure to open a sufficient number of windows before assigning the desired shortcuts (assuming they had actually figured out why there was a varying number of shortcuts, which most probably didn't).

So after some discussions with designers, it was decided that exposing a fixed number of shortcuts was a far less confusing approach. I assume you can agree with that, even though you obviously don't agree with the number we picked.

The idea there was not that no one would ever use more than 4 workspaces, but that *most* users would not use more (as a data point, both Fedora and Ubuntu have used a default number of two workspaces with GNOME 2.x for years). When you examined the keybinding settings with dconf, you may have noticed that there are a number of shortcuts that don't appear in the UI; the reason is that showing lesser used entries in the list is not without drawbacks - it makes it harder to locate the commonly used entries. So between users who don't use workspaces at all and users who use 36 (the arbitrary limit used by metacity/mutter), 16 (the arbitrary limit used by gnome-shell) or 12 (the arbitrary limit of available keybindings[0]) workspaces, four looked like a good compromise (also keep in mind that there's a "move-to-workspace-n" shortcut for every "switch-to-workspace-n" one, so exposing the full set would result in a whopping 24 entries hardly anyone would use).


> Hopefully this will get fixed in the next update, it's a *really* irritating
> limitation added for no reason.

I hope I have been able to make it clear that the limitation has not been made entirely without reason :)

That said, I don't consider the current limitation of 4 as set in stone; 12 is clearly (IMHO of course) over the top, but going to 6[1] might be fine (in particular as I expect us to remove the "switch workspace left/right" shortcuts, that don't make any sense in gnome-shell). Revisiting the list of keybindings is on my list, I'll make sure to bring up this issue with the designers. I'll also try to remember to link to the appropriate upstream bug here once it exists.



> Thanks, it shows up one can also do it manually using the magic dconf
> tool setting undocumented variables, like this:
> 
> dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-5
> [\'\<Alt\>F5\']

[offtopic]: You should not use "dconf" directly, but rather the gsettings frontend - gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-5 '["<Alt>F5"]'



[0] there's an obvious reasoning of "most users will use a shortcut that involves a function key, and there are commonly twelve function keys" here, but it's still kind of arbitrary
[1] somehow I expect us to pick an even number, no idea for what silly reason
Comment 4 Jes Sorensen 2012-06-05 12:36:49 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > Whoever wrote the keybindings tool just didn't seem to think anybody should
> > need workspaces > 4 :(
> 
> It is a bit more complicated than that :)
> 
> The way it used to work was to show one "switch to workspace <n>" keybinding
> in System Settings for each workspace. This was fine as long as the number
> of workspaces was a user preference, but not a good fit for GNOME 3's
> dynamic model - basically users had to make sure to open a sufficient number
> of windows before assigning the desired shortcuts (assuming they had
> actually figured out why there was a varying number of shortcuts, which most
> probably didn't).
> 
> So after some discussions with designers, it was decided that exposing a
> fixed number of shortcuts was a far less confusing approach. I assume you
> can agree with that, even though you obviously don't agree with the number
> we picked.

The dynamic workspaces are of course the fundamental problem here. I run
the extension to get back my static workspaces, like every developer I
have spoken to. I rely on having my work areas in fixed places and I jump
to them with the hotkeys. Having to guess which workspace has my web
browser and which has my Emacs hacking space depending on which was launched
first and whether firefox has died and renumbered everything in the process
does one thing - make me want to throw my computer out the window. This is
one of the fundamental design flaws in gnome-shell - trying to force people
to use the %#$%#$ dynamic workspaces is just plain wrong. Having it as an
option is all great, but forcing it on people is not :(

Anyway, I doubt we will ever agree on that part. I do follow your
explanation, I just wish the infrastructure would do the right thing.

> > Hopefully this will get fixed in the next update, it's a *really* irritating
> > limitation added for no reason.
> 
> I hope I have been able to make it clear that the limitation has not been
> made entirely without reason :)

Yes, unfortunately this limit is one of the many items I keep on my
'how to make gnome 3 somewhat usable' list. The list is way way too long 
unfortunately :(

> That said, I don't consider the current limitation of 4 as set in stone; 12
> is clearly (IMHO of course) over the top, but going to 6[1] might be fine
> (in particular as I expect us to remove the "switch workspace left/right"
> shortcuts, that don't make any sense in gnome-shell). Revisiting the list of
> keybindings is on my list, I'll make sure to bring up this issue with the
> designers. I'll also try to remember to link to the appropriate upstream bug
> here once it exists.

I don't think 6 is a good number - sticking to 12 as the number of function
keys on the keyboard is probably better, and less likely to have flamewars
launched over it.

> > Thanks, it shows up one can also do it manually using the magic dconf
> > tool setting undocumented variables, like this:
> > 
> > dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-5
> > [\'\<Alt\>F5\']
> 
> [offtopic]: You should not use "dconf" directly, but rather the gsettings
> frontend - gsettings set org.gnome.desktop.wm.keybindings
> switch-to-workspace-5 '["<Alt>F5"]'

Ok, I am clueless here - what is the difference? I found dconf using google
at some point and it was able to set the things. Can I browse the tree of
potential bindings using gsettings?

Note here that it is also extremely frustrating that not all possible
settings are visible when you do 'dconf list', so one has to guess what
might work and use trial and error.

Once again, I appreciate the explanation. I hope a fix, even if a
temporary one to bump the number to 12 can get pushed out asap.

Thanks,
Jes
Comment 5 Patrick C. F. Ernzer 2012-06-05 13:25:08 EDT
*** Bug 828982 has been marked as a duplicate of this bug. ***
Comment 6 Matthias Clasen 2012-06-05 13:30:00 EDT
(In reply to comment #4)


> Ok, I am clueless here - what is the difference? I found dconf using google
> at some point and it was able to set the things. Can I browse the tree of
> potential bindings using gsettings?
> 
> Note here that it is also extremely frustrating that not all possible
> settings are visible when you do 'dconf list', so one has to guess what
> might work and use trial and error.

Try gsettings, it has commandline completion. eg

gsettings list-keys org.gnome.desktop.<TAB>
Comment 7 Florian Müllner 2012-06-07 10:54:17 EDT
(In reply to comment #4)
>  This is one of the fundamental design flaws in gnome-shell - trying to 
> force people to use the %#$%#$ dynamic workspaces is just plain wrong. 
> Having it as an option is all great, but forcing it on people is not :(

gsettings set org.gnome.shell.overrides dynamic-workspaces false


> I don't think 6 is a good number - sticking to 12 as the number of function
> keys on the keyboard is probably better, and less likely to have flamewars
> launched over it.

I'm pretty sure that won't happen. There are about 6-8 shortcuts in that section that are generally useful to most users, adding 16 entries that are not will make it harder to locate relevant entries them.
Comment 8 Jeff Bastian 2012-06-20 18:10:32 EDT
gnome-tweak-tool in 3.4 now has a setting to disable dynamic workspaces and pick a fixed number of workspaces (no more need for Frippery extension).  If it can do this, then surely the Keyboard Settings GUI can expose the correct number of hotkeys to match the number of workspaces.

if dynamic workspaces enabled
  show hotkeys for workspaces 1-4
else
  show hotkeys for 1-N where N is the number of fixed workspaces
Comment 9 Jeff Bastian 2012-06-20 18:31:12 EDT
(In reply to comment #7)
> gsettings set org.gnome.shell.overrides dynamic-workspaces false


And this is useful too for 12 fixed workspaces:

 gsettings set org.gnome.desktop.wm.preferences num-workspaces 12
Comment 10 Jeff Bastian 2012-06-20 18:40:15 EDT
Created attachment 593319 [details]
script to tweak workspaces and hotkeys

The attached script disables dynamic workspaces, sets 12 fixed workspaces, and sets the switch-to and move-window-to hotkeys for all 12.  I like CTRL-Fn for switching and CTRL-SHIFT-Fn for move-window.
Comment 11 John Brier 2012-06-21 13:12:00 EDT
(In reply to comment #8)
> gnome-tweak-tool in 3.4 now has a setting to disable dynamic workspaces and
> pick a fixed number of workspaces (no more need for Frippery extension).  If
> it can do this, then surely the Keyboard Settings GUI can expose the correct
> number of hotkeys to match the number of workspaces.
> 

However at least a week or two ago I experienced personally and read others report the same (on a website I didn't save) that you can't click and drag and drop applications from one workspace to another using gnome's static work space support, so back to frippery it was for me.
Comment 12 Jeff Bastian 2012-06-21 13:32:44 EDT
Yeah, I just discovered that a few minutes ago!  Argh.

Fortunately I can still move things around with the keyboard shortcuts.
Comment 13 Petr 2012-11-27 03:25:33 EST
Thanks for the useful command line tricks! However, it works for me only partially, something keeps setting the number of workspaces back!
So, I start with dynamic workspaces, there is 5 of them. Then I switch to static workspaces and successfully change the number to 9. However, after a short while, the number of workspaces is 5 again! Any ideas?

$ gsettings list-recursively org.gnome.shell.overrides | grep dynamic-workspaces
org.gnome.shell.overrides dynamic-workspaces true

$ gsettings list-recursively org.gnome.desktop.wm.preferences | grep num-workspaces
org.gnome.desktop.wm.preferences num-workspaces 5

$ gsettings set org.gnome.shell.overrides dynamic-workspaces false
$ gsettings set org.gnome.desktop.wm.preferences num-workspaces 9
$ gsettings list-recursively org.gnome.shell.overrides | grep dynamic-workspaces
org.gnome.shell.overrides dynamic-workspaces false

$ gsettings list-recursively org.gnome.desktop.wm.preferences | grep num-workspaces
org.gnome.desktop.wm.preferences num-workspaces 9

$ sleep 3
$ gsettings list-recursively org.gnome.shell.overrides | grep dynamic-workspaces
org.gnome.shell.overrides dynamic-workspaces false
$ gsettings list-recursively org.gnome.desktop.wm.preferences | grep num-workspaces
org.gnome.desktop.wm.preferences num-workspaces 5
Comment 14 Fedora End Of Life 2013-07-03 18:28:49 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 15 Andre Klapper 2013-08-21 16:46:14 EDT
If I don't get it wrong, it's possible, see https://bugzilla.gnome.org/show_bug.cgi?id=680500#c1
Comment 16 Fedora End Of Life 2015-01-09 12:10:14 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 17 Fedora End Of Life 2015-02-17 09:16:11 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.