GNOME Bugzilla – Bug 710398
Input method indicator of ibus-kkc disappears when all other input methods except ibus-kkc are removed while ibus-kkc is active
Last modified: 2021-07-05 14:08:43 UTC
1) Fedora 20 Beta TC4, gnome-shell-3.10.0.1-1.fc20.x86_64 2) Installation in Japanese 3) After logging in to gnome, there are 2 input methods selectable in the panel: - あ (ibus-kkc) - en (US English keyboard layout) 4) start “gnome-control-center region” One can see the 2 input methods listed there as well. a) 5a) select あ (ibus-kkc) in the panel 6a) Click on 英語(US) in “gnome-control-center region” and click on the [-] button to remove it. → The input method indicator vanishes from the panel 7a) type Alt+F2 and type “r” in the “Enter Command” dialog (as ibus-kkc is active, switch to direct input using Alt+@ to be able to input the Latin “r”) → The input method indicator of ibus-kkc appears again. (Restarting the gnome session achieves the same) Now add the US English keyboard back to go back to step 5): b) 5b) select “en” (US English keyboard) in the panel 6b) Click on 英語(US) in “gnome-control-center region” and click on the [-] button to remove it. → The input method indicator does *not* vanish from the panel! Expected behaviour: The input method indicator for ibus-kkc should never vanish from panel, even if ibus-kkc is the only input method left. Because it is needed to show the different modes of ibus-kkc (Hiragana, Katakana, Halfwidth-Katakana, Latin, Full-Width-Latin, Direct-Input)
The behaviour is the same no matter whether gnome or gnome-classic is used.
This is not specific to ibus-kkc of course - I suppose it affects all IMEs. I just tried with ibus-libpinyin too under gnome-shell-3.10.0.1 and saw the indicator disappearing in the same way when removing the only configured layout. (So would be good to update the summary to reflect that.) I stared a bit at gnome-shell/js/ui/status/keyboard.js but I haven't tracked down the code that is causing this yet. I guess the hiding of the indicator is over-eager in this case.
(same also with gnome-shell-3.10.1)
It is strange that the result depends on the current set input source when removing the kbd layout: Case 1: - kkc is current input source - remove US layout => input indicator disappears Case 2: - us layout is current input remove - remove US layout => input indicator switches to kkc as current input source. This seems to suggest that newSource in _currentInputSourceChanged (gnome-shell/js/ui/status/keyboard.js) somehow depends on the current input source before removing the layout, and yet hasn't _inputSourcesChanged just updated the _inputSources... Anyway I am not so familiar with debugging gjs. I looked a bit at gnome-settings-daemon-3.10.1/plugins/keyboard/gsd-keyboard-manager.c to try to understand how org.gnome.desktop.input-sources.current would get reset when an input source is removed say.
Created attachment 257653 [details] [review] status/keyboard: Don't lose IBus engine properties when sources change The input sources list changing doesn't necessarily mean that the current IBus engine changed. This means that we won't get the global-engine-changed signal which in turn means that the new InputSource instance we just created for the current engine won't have properties. Moving the properties from the old matching instance to the new one fixes this.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.