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:
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).
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
(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
(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
*** Bug 828982 has been marked as a duplicate of this bug. ***
(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>
(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.
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
(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
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.
(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.
Yeah, I just discovered that a few minutes ago! Argh. Fortunately I can still move things around with the keyboard shortcuts.
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
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.
If I don't get it wrong, it's possible, see https://bugzilla.gnome.org/show_bug.cgi?id=680500#c1
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.
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.