GNOME Bugzilla – Bug 115584
Extensible way to talk about workspaces in GConf
Last modified: 2020-11-06 20:05:58 UTC
gnome-keybinding-properties allows only 12 keybindings to be associated to switch between workspaces, whereas user can add more workspaces. To reproduce: - Add workspace switcher applet to panel and select 20 workspaces from the preferences dialog. - Now open gnome-keybinding-properties dialog and check the keybinding entries for workspace switching User is allowed to associate only 12 keybindings to the workspaces. In other words, user can bind keys to switch to 12 workspaces only. There should not be limitation in keybindings when user is allowed to add more workspaces? It impacts the users using more workspaces across monitors(multihead setup)
Some customers are specifically asking for more than 12 keybindings. Also, when I decrease number of workspaces from(say 10 to 4), the gnome-keybinding-properties shows the descreased number of keybindings . But when I increase the workspaces(say from 4 to 14), the number of keybindings shown increases till 12 only. There is an inconsistency in this behaviour. Any comments ? Should I submit a patch?
A patch would probably be a good idea to get discussion going :)
I have worked out one for Solaris. I will have to work out a similar one for Linux CVS HEAD and submit. I will do it soon.
The code changes are falling into metacity as well as gnome-control-center. The metacity patch looks really big as I am adding schemas for the keybindings from 13 to 36. The changes are repititive. I have just cut-pasted the existing code for adding a keybinding. I will attach both the patches.
Created attachment 18052 [details] [review] proposed changes to gnome-control-center
Created attachment 18053 [details] [review] proposed changes for metacity
I'm happy to apply this to the control-center, but not until the metacity bit is applied first. Havoc, are you happy with moving that out to 20? If so, I can apply either/both.
Filed a bug dep against metacity so it's more likely to be seen by the relevant people.
Of course, metacity currently only allows up to 32 total keybindings, so having 36 keybindings for just workspaces seems somewhat silly. I had proposed before to add support for an arbitrary number of keybindings but we decided at that time to just limit it to 32. Currently metacity only installs schemas for the first 12 though, even though it supports up to 32.
Can we just consolidate all the schemas, so we apply one schema to 32 keys instead of having 32 schemas? I guess that makes the control center UI break. A GNOME 2.6 issue in any case.
As metacity now ships its own keybindings definition, punting to metacity.
So here's my idea: We continue to support the 12 keys we always have, but we deprecate them. We add new keys window_keybindings/move_to_workspace global_keybindings/switch_to_workspace workspace_names/name (or possibly general/workspace_names) Either we allow each of these to be a list of strings of the form <natural number>+"="+<string>, or alternatively we allow them to be a semicolon-separated list of such strings. Note that the attached patches are broken because they * rename the key for the name of the 12th workspace to namee12 * introduce new run-commands even though that wasn't specified * and replicate keys pointlessly, but we've covered that.
(Sorry, the paragraph about their type was unclear. I meant they could be a list thus: window_keybindings/move_to_workspace (LIST): * 1=Super-1 * 2=Super-2 or a string thus: window_keybindings/move_to_workspace (STRING): 1=Super-1;2=Super-2 The first one allows you to have arbitrary characters in the value (after the equals sign) but the second one is probably easier for people using gconf-editor to add and edit.
I don't see the purpose of causing the user pain of deprecating the old keys, or the developer pain of writing that new code. There is no need to support N keybindings. 12 is fine, imo. But even if we satisfy the extremists of the world, 32 is fine. There is no way in hell we need 64 - anyone with 64 workspaces does not need per-workspace keybindings, and if they really, really want them they can do something custom with libwnck or devil's pie or another WM. We _definitely_ don't need N, since even 64 is ludicrous. So just KISS, do the simplest thing that can possibly work, choose your cliche... it's simple to just change the current 12 to a higher number and not do anything else. (as a side note, cramming all the bindings in a single gconf key makes the control center part a big pain to implement, and introduces a very theoretical race condition since you have to read-modify-write the setting)
Well, the simplest *possible* thing is to change this bug to WONTFIX and wash our hands of it. It's pretty trivial for the (very) few people who want to bind more than twelve keybindings to patch it downstream (or, as you say, use devil's pie or something else). I'm actually wondering now what kind of keyboard someone with 64 keybound workspaces would have. I am thinking something like this: http://commons.wikimedia.org/wiki/Image:ConsoleOrgueWanamaker.jpg WONTFIX, then?
Sounds good to me. :-) Though maybe notgnome (i.e. can be done in devilspie or separate add-on, so it's not really won't-be-fixed, just a won't-be-fixed-by-changing-metacity.)
okay, notgnome.
*** Bug 511902 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > I don't see the purpose of causing the user pain of deprecating the old keys, > or the developer pain of writing that new code. There is no need to support N > keybindings. 12 is fine, imo. 12 may be fine for you, but not neccessarily for others. for people using more workspaces (personally i use 16, like also mac osx leopard has it for instance), the missing abilitiy to assign key bindings to the last 4 workspaces is a significant usability issue. > So just KISS, do the simplest thing that can possibly work, choose your > cliche... it's simple to just change the current 12 to a higher number and not > do anything else. KISS for the developer or for the user? fact is, the current limitation does *not* work for users with more than 12 workspaces, so you can keep things simple *after* you've made them work ;) Bug 511902 even links to a patch to extend the current range, because someone was bothered enough to actually dive into the code. (In reply to comment #15) > Well, the simplest *possible* thing is to change this bug to WONTFIX and wash > our hands of it. It's pretty trivial for the (very) few people who want to > bind more than twelve keybindings to patch it downstream (or, as you say, use > devil's pie or something else). i can't really believe that patch-it-downstream is considered a suitable answer to a window manager usability bug. in case this is not clear, most metacity users can *not* patch the binaries they are running. possibly many people do want more than 12 workspaces though, e.g. poeple used to 16 workspaces from OS X. not all of those are developers, so "patching" is not a solution, it's part of the problem. reopening, because fixing this bug was requested by multiple parties now.
(In reply to comment #19) Tim: You might want to respond in the light of <http://ometer.com/features.html>; in particular > Bug 511902 even links to a patch to extend the current range, because someone > was bothered enough to actually dive into the code. "Please don't assume that the key issue for accepting a feature is whether there's a patch. It isn't." > possibly many people do want more than 12 workspaces though "Bad rationales which apply to all possible features include: Some (unknown number of) people might like it (for some unknown reason)." > e.g. poeple used to 16 workspaces from OS X. "...Some other operating system had the feature."
The patch as it was given just adds more keys to the schemas. This isn't the way to do it. You should patch the keybindings capplet to recognise keys lists, and use them in metacity instead. I don't think the read/write race is really something that would be a problem though.
(In reply to comment #20) > (In reply to comment #19) > Tim: You might want to respond in the light of > <http://ometer.com/features.html>; in particular if you are really interested in a more general treatment of feature additions from my part, you can read up on that here: http://blogs.gnome.org/timj/2005/12/14/14122005-never-reject-a-feature/ > > Bug 511902 even links to a patch to extend the current range, because someone > > was bothered enough to actually dive into the code. > > "Please don't assume that the key issue for accepting a feature is whether > there's a patch. It isn't." i don't, i maintain enough projects myself to know that. presence of patches shows that someone was motivated enough to bother though. > > possibly many people do want more than 12 workspaces though > > "Bad rationales which apply to all possible features include: Some (unknown > number of) people might like it (for some unknown reason)." this is a mis-argument, for every feature you can find *someone* who doesn't want it, and without clairvoyance you can always claim vagueness about the number of requesters. one bug being filed already raises "unknown number" to 1, dups add up to that. and the reasons have been presented for this particular bug. > > e.g. poeple used to 16 workspaces from OS X. > > "...Some other operating system had the feature." which is not a counterargument. it can indeed indicate that the particular feature might be very relevant. and it allmost always can be a significant usability argument in terms of consistency (which doesn't imply that one desktop aproach should copy the other blindly). there is no canonical reasoning for all bug reports, and for every argument a counter argument can be found, so this sort of generic arguing is leading nowhere. it doesn't change the fact that some people suffer from a usability problem and will be happy if it is fixed. when a developer starts optimizing towards reducing usability problems and making users happy, development is on the right track and evaluating the specifics of each report will come naturally that way.
As a new user, I would like to offer input on this feature request. I've switched over from Enlightenment, where I used 24 workspaces, which did support creating shortcuts for accessing more than 12 workspaces. I keep more than 12 applications or shells open. It's a handy feature to be able to switch quickly to the application or shell that I want to access. I always keep applications running in the same workspace... using workspaces this way makes me more efficient and productive, and certainly keeps me from 'hunting' around for the right window, and keeps my use of the mouse way down. Alt-tab does not work very well for me. Ctrl-Alt-up/down/right/left is the work around that I currently use, but it's still too slow.
Created attachment 125350 [details] [review] Updated patch for Metacity 2.22.0 This is an update of the previous patch (from 2003) for Metacity 2.22.0. However, it does not increase the maximum number of keybindings that Metacity supports, since I'm not sure what the appropriate value would be.
Review of attachment 125350 [details] [review]: I still think this is solving the wrong problem. We support switching between "n" workspaces, each effectively a special case. This patch increases "n". I would rather see a generalised way that "n" could be specified, if we're going to attack this problem at all (which is still not a settled issue).
This bug just needs to put up or shut up. It's over 9 years old. Those of us who believe this is functionality that improves the utility of metacity have put up. To reiterate an old argument without providing code is merely deflecting the problem. If someone could summarize what would be entailed in implementing a generalized approach, I'd be willing to do some grunt work on this, but a generalized approach sounds like a lot of work to fix something that's already been fixed. What exactly is the argument against increasing n?
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.