GNOME Bugzilla – Bug 736436
keyboard: Remove input sources handling
Last modified: 2014-10-22 11:01:41 UTC
See bug 736435. This still leaves the logic to migrate and setup initial settings in g-s-d. I'm not entirely sure what to do about that.
Created attachment 285857 [details] [review] keyboard: Remove input sources handling All of this functionality is moving into mutter/gnome-shell so that both wayland and X sessions follow the same code paths as closely as possible.
Review of attachment 285857 [details] [review]: Looks good after the freeze.
We decided to push this on IRC. Attachment 285857 [details] pushed as 326ee9f - keyboard: Remove input sources handling
Hi, I am not sure how this can be marked as resolved. If prior to this commit one could switch current input-source programmatically with "gsettings set org.gnome.desktop.input-sources current 1" now it isn't possible. If one tries to fallback to switching directly via xkb api, then the switch happens but the g-s-d indicator does not reflect the switch. Does there exist an alternative way (in mutter/gnome-shell) for switching the layout yet? If not, then this bug should probably remain open (since a useful functionality was removed and not brought back).
That functionality was never advertised as public. Why did you need it? What's the use case?
If you have more than 2 different input sources, it is nice to switch directly to the required input source by, say, capslock+1 to English, capslock+2 to Estonian, capslock+3 to Russian, instead of cycling through all the input sources. (This functionality, e.g., has for a long time been included in Windows, since 2000 maybe even before.) Prior to Gnome 3.6 it was possible to use xkb api (keyboard indicator was aware of the changes to xkblockgroup then). See http://amanick.blogspot.com/2010/07/if-you-ever-wanted-to-change-xkb-layout.html for details. However, since then the only option has been to use gsettings api. That is, until the commit in question.
Hi! A glance at https://git.gnome.org/browse/gnome-shell/tree/js/ui/status/keyboard.js and experiments in lg reveal that the only fix needed is something like this._settings.connect('changed::current', function(){this._inputSources[this._settings.get_uint('current')].activate()}); just after line 176 and something like this._settings.set_strv('current', newSource.index) somewhere in InputSourceManager#_currentInputSourceChanged. Could you please implement it? Or do you want me to submit a proper patch?
No I don't plan on supporting that gsettings key anymore. It was a mistake to have it in the first place. You are free to do a gnome-shell extension if you want.
Do you plan on reimplementing direct switching in any other way? (I assume listening to XKB index change is not an option either. Or is it?) As for an extension, I am sorry for my ignorance and I would appreciate if you could help (I never did any development for gnome-shell), but is there any other way of getting to InputSourceManager instead of Main.panel._rightBox.get_children()[2].get_first_child()._delegate._inputSourceManager ? Is it published somewhere for easy access? Because the former is a hack, which would not even always work (the index [2] sometimes becomes [1]). IMHO, if you do plan to support direct switching, the gsettings api call is a simple and easy-to-support solution (besides staying the same API as before). If you don't, it is quite a shame. And the following may be a rant (sorry for this)... but I think it becomes harder and harder to convert Windows users to Gnome, because it seems to be losing important functionality that is assumed to be there in a modern DE. I am sure that direct switching is a must have if you want to work efficiently and have more than two keyboard layouts. This is the way most of my fellow devs do things (in different DEs).
(In reply to comment #9) > Do you plan on reimplementing direct switching in any other way? (I assume > listening to XKB index change is not an option either. Or is it?) It isn't because there are only 4 of those indexes and we allow for more that 4 input sources which means that we sometimes change the whole keymap and at that point an XKB index doesn't mean one input source anymore. > As for an extension, I am sorry for my ignorance and I would appreciate if you > could help (I never did any development for gnome-shell), but is there any > other way of getting to InputSourceManager instead of > Main.panel._rightBox.get_children()[2].get_first_child()._delegate._inputSourceManager > ? > Is it published somewhere for easy access? Because the former is a hack, which > would not even always work (the index [2] sometimes becomes [1]). const InputSourceManager = imports.ui.status.keyboard.getInputSourceManager(); > IMHO, if you do plan to support direct switching, the gsettings api call is a > simple and easy-to-support solution (besides staying the same API as before). It's not because then we should also update the setting and that's exactly why I wanted to move away from it, because gsettings are not really meant for IPC and writing settings all the time sucks because it causes writes to the disk. > If you don't, it is quite a shame. And the following may be a rant (sorry for > this)... but I think it becomes harder and harder to convert Windows users to Does Windows allow this? How does it work? > Gnome, because it seems to be losing important functionality that is assumed to > be there in a modern DE. I'm not sure it's that important since yours is the first report about it that I've seen in the last 3 years. > I am sure that direct switching is a must have if you want to work efficiently > and have more than two keyboard layouts. This is the way most of my fellow devs > do things (in different DEs). So, do an extension and maybe if it gets really popular we might change our minds on this.
(In reply to comment #10) > > const InputSourceManager = imports.ui.status.keyboard.getInputSourceManager(); > Great! Thanks. >It's not because then we should also update the setting and that's exactly why >I wanted to move away from it, because gsettings are not really meant for IPC >and writing settings all the time sucks because it causes writes to the disk. I see. Is there maybe a way to run arbitrary shell js on custom shortcuts with some command? This might be a (better) solution then. On the other hand, I do not see why there should not be some runtime values in gsettings which do not get written to disk every time (just on shutdown). Hasn't anyone ever needed that? > Does Windows allow this? How does it work? Last times I checked (in XP and 7) it was configurable directly in the keyboard layouts' shortcuts dialog. Ideally, IMHO one would like to see the same in Gnome. But if there is some certain command allowing that, it should be good enough. > > Gnome, because it seems to be losing important functionality that is assumed to > > be there in a modern DE. > > I'm not sure it's that important since yours is the first report about it that > I've seen in the last 3 years. Because it worked.:) > > I am sure that direct switching is a must have if you want to work efficiently > > and have more than two keyboard layouts. This is the way most of my fellow devs > > do things (in different DEs). > > So, do an extension and maybe if it gets really popular we might change our > minds on this. I will once I figure out what's the best way to do it if gsettings API is to be avoided. Thank you for the answers!
Hi, sorry for all the spam, but it is finally clear to me what would currently be a nice way to do this. It is simply to add shortcuts "Switch to input source 1", ..., "Switch to input source #n" (where n is, say, 4 or 8) in the "Typing" section of default shortcuts (that is, add keys to 'org.gnome.desktop.wm.keybindings' schema). This would be similar to currently existing "move-to-workspace-#n" keybindings. And the implementation in ui/support/keboard.js should be easy for this. (It boils down to simply calling inputSources[#n].activate()). This would provide a benefit of working also in gdm. What do you think about it? Should I file a feature request for this (because it is a new feature)? It seems to me it is not possible to do exactly the same thing with an extension, because you can't change 'org.gnome.desktop.wm.keybindings' schema from extension. So an extension pref should either reimplement keybinding chooser dialog or not worry about keybindings clashes.
(In reply to comment #12) > It is simply to add shortcuts "Switch to input source 1", ..., "Switch to input > source #n" (where n is, say, 4 or 8) in the "Typing" section of default > shortcuts (that is, add keys to 'org.gnome.desktop.wm.keybindings' schema). > This would be similar to currently existing "move-to-workspace-#n" keybindings. > And the implementation in ui/support/keboard.js should be easy for this. (It > boils down to simply calling inputSources[#n].activate()). > This would provide a benefit of working also in gdm. > > What do you think about it? Should I file a feature request for this (because > it is a new feature)? yeah, it has crossed my mind that it could be done like that. Feel free to open an enhancement bug in gnome-shell for it. Even better if you attach patches :-) > It seems to me it is not possible to do exactly the same thing with an > extension, because you can't change 'org.gnome.desktop.wm.keybindings' schema > from extension. So an extension pref should either reimplement keybinding > chooser dialog or not worry about keybindings clashes. You can have your own schema in an extension.
The enhancement bug: bug 738975