1) type “ibus restart” in a terminal 2) choose the any input source which is not just a keyboard layout (I can reproduce the problem with any input source I tried: -- ibus-kkc -- ibus-anthy -- ibus-mozc -- ibus-cangjie -- ibus-libpinyin -- ibus-table ) 3) type something into the terminal and verify the input method works 4) type arrow up until you get “ibus restart” from the history 5) type return 6) now the input method choosen in step 2) has stopped working although it is still shown in the input method indicator. I.e. you still see “あ” for the Japanese input methods in the indicator but it does not work. 7) switch to some other input source 8) switch back the input source choosen in 2) -> now it works again I would expect that the current selected input source is properly restarted and keeps working when calling “ibus restart”.
I think the problem exists in GNOME only. And probably the original problem is changed in f21. gnome-shell resets the engine to the fist one whenever ibus-daemon restarts in f21. It seems _inputSourcesChanged() in ui/status/keyboard.js is called in both start and restart.
(In reply to fujiwara from comment #1) > I think the problem exists in GNOME only. > And probably the original problem is changed in f21. > gnome-shell resets the engine to the fist one whenever ibus-daemon restarts > in f21. I can reproduce the problem both on f20 and f21 (Fedora-Live-Workstation-x86_64-21_Alpha-1.iso) > It seems _inputSourcesChanged() in ui/status/keyboard.js is called in both > start and restart.
Fedora-Live-Workstation-x86_64-21_Alpha-1.iso has gnome-shell-3.13.92-1.fc21.x86_64
I'm aware of this and it could probably be fixed but it's not high on my TODO list since restarting ibus-daemon isn't something that should happen in normal usage.
The problem is that it does happen on a normal usage. Namely, when you start gnome and have RU at startup, it works as if it is EN. You need to switch twice to get a real RU.
What are the specific steps to reproduce that? Which input sources do you have configured? Which package versions (gnome-settings-daemon and gnome-shell) ?
Add EN (English USA) and RU (Russian legacy). Before logging out, set RU on the last window. gnome will remember that and will set RU on next start-up. Reboot, just in case. On next start-up you'll get RU, but this will not work as RU until you switch twice. Of course since you say your new gnome no longer saves the last layout, you may not reproduce it that way. Instead, you can use "ibus restart" as an easy way of reproducing.
$ rpm -q gnome-settings-daemon gnome-settings-daemon-3.8.6.1-1.fc19.x86_64 $ rpm -q gnome-shell gnome-shell-3.8.4-3.fc19.x86_64
(In reply to Stas Sergeev from comment #7) > Add EN (English USA) and RU (Russian legacy). > Before logging out, set RU on the last window. > gnome will remember that and will set RU on > next start-up. Reboot, just in case. > On next start-up you'll get RU, but this will > not work as RU until you switch twice. > Of course since you say your new gnome no longer > saves the last layout, you may not reproduce > it that way. Instead, you can use "ibus restart" > as an easy way of reproducing. I can't reproduce this on F20. Are these 2 the only sources you have configured? Can you confirm that their labels are "English (US)" and "Russian (legacy)"? If that's the case then ibus doesn't even enter the picture since both are plain xkb keyboard layouts. Can you try to create a new user account and see if you can reproduce there?
(In reply to Rui Matos from comment #9) > (In reply to Stas Sergeev from comment #7) > Are these 2 the only sources you have configured? Can you confirm that their > labels are "English (US)" and "Russian (legacy)"? > > If that's the case then ibus doesn't even enter the picture since both are > plain xkb keyboard layouts. No, the “Russian legacy” Stas is using is an ibus-table input method: $ rpm -qf /usr/share/ibus-table/tables/rusle.db ibus-table-cyrillic-1.3.4-1.fc20.noarch mfabian@ari:~ $ ibus list-engine | grep rusle table:rusle - rusle mfabian@ari:~ $ > Can you try to create a new user account and see if you can reproduce there?
(In reply to Rui Matos from comment #9) > I can't reproduce this on F20. Not sure, I tried F19. > Are these 2 the only sources you have configured? Can you confirm that their > labels are "English (US)" and "Russian (legacy)"? Exactly, "English (US)" and "Russian (Русская(устаревшая))" (yes, even after LC_ALL=C its still "Russian (Русская(устаревшая))" for some reasons) org.gnome.desktop.input-sources sources [('xkb', 'us'), ('ibus', 'table:rusle')] > Can you try to create a new user account and see if you can reproduce there? Reproduced on new account. Any more info I need to provide?
(In reply to Stas Sergeev from comment #11) > > Are these 2 the only sources you have configured? Can you confirm that their > > labels are "English (US)" and "Russian (legacy)"? > Exactly, "English (US)" and "Russian (Русская(устаревшая))" That is because rusle.txt, the table source, contains: ### The default name of this table NAME = RussianLegacy2 ### The local names of this table NAME.ru_RU = Русская (устаревшая) > (yes, even after LC_ALL=C its still "Russian (Русская(устаревшая))" > for some reasons) You run your Gnome Desktop in LC_ALL=C ?
(In reply to Stas Sergeev from comment #11) > (In reply to Rui Matos from comment #9) > > I can't reproduce this on F20. > Not sure, I tried F19. I cannot reproduce this on F21 Alpha and I could not reproduce it on F20 either so far.
(In reply to Mike FABIAN from comment #12) > That is because rusle.txt, the table source, contains: > > ### The default name of this table > NAME = RussianLegacy2 > > ### The local names of this table > NAME.ru_RU = Русская (устаревшая) Would you mind adding something like NAME.en_US = Russian (legacy) please? > > (yes, even after LC_ALL=C its still "Russian (Русская(устаревшая))" > > for some reasons) > You run your Gnome Desktop in LC_ALL=C ? No, I simply did LC_ALL=C gnome-control-center before copying things here. (In reply to Mike FABIAN from comment #13) > I cannot reproduce this on F21 Alpha and I could not reproduce it on > F20 either so far. What exactly happens? You get RU at start-up and it works properly as RU? Then it is specific to F19 somehow.
(In reply to Stas Sergeev from comment #14) > Would you mind adding something like > NAME.en_US = Russian (legacy) > please? Or should it be just "legacy"? It seems "Russian" is appended from some other source. Then likely the following is needed: NAME.ru_RU = устаревшая NAME.en_US = legacy
(In reply to Stas Sergeev from comment #14) > (In reply to Mike FABIAN from comment #12) > > That is because rusle.txt, the table source, contains: > > > > ### The default name of this table > > NAME = RussianLegacy2 > > > > ### The local names of this table > > NAME.ru_RU = Русская (устаревшая) > Would you mind adding something like > NAME.en_US = Russian (legacy) > please? OK, checking your next comment as well ... > > > (yes, even after LC_ALL=C its still "Russian (Русская(устаревшая))" > > > for some reasons) > > You run your Gnome Desktop in LC_ALL=C ? > No, I simply did > LC_ALL=C gnome-control-center > before copying things here. That does change the UI of gnome-control-center but not the names of the input sources. Because these are supplied by ibus. So without restarting the ibus-daemon, these won’t change. > (In reply to Mike FABIAN from comment #13) > > I cannot reproduce this on F21 Alpha and I could not reproduce it on > > F20 either so far. > What exactly happens? > You get RU at start-up and it works properly as RU? Yes. I get "ru" at start-up and it works properly. > Then it is specific to F19 somehow. Strange.
(In reply to Stas Sergeev from comment #15) > (In reply to Stas Sergeev from comment #14) > > Would you mind adding something like > > NAME.en_US = Russian (legacy) > > please? > Or should it be just "legacy"? It seems "Russian" is > appended from some other source. Yes, from ### Supported languages of this table LANGUAGES = ru_RU This should probably only be "ru", not "ru_RU" (because Russian is the same in RU and UA) > Then likely the following is needed: > > NAME.ru_RU = устаревшая > NAME.en_US = legacy Trying ...
(In reply to Mike FABIAN from comment #16) > > No, I simply did > > LC_ALL=C gnome-control-center > > before copying things here. > That does change the UI of gnome-control-center but not the names of > the input sources. But it changed "Английская (США)" to "English (US)", and it changed "Русский (Русская(устаревшая))" то "Russian (Русская(устаревшая))", so to some degree it worked. :)
(In reply to Stas Sergeev from comment #18) > (In reply to Mike FABIAN from comment #16) > > > No, I simply did > > > LC_ALL=C gnome-control-center > > > before copying things here. > > That does change the UI of gnome-control-center but not the names of > > the input sources. > But it changed "Английская (США)" to "English (US)", and > it changed "Русский (Русская(устаревшая))" то "Russian > (Русская(устаревшая))", > so to some degree it worked. :) The part before (Русская(устаревшая)) is done by gnome-conrol-centre, which gets "ru_RU" as the supported language and translates it. The part (Русская(устаревшая)) is the localized engine name originally from the table source wich is used unchanged as supplied by ibus. And “"Английская (США)" to "English (US)"” is a keyboard layout, not an input engine, this is something differnent.
(In reply to Mike FABIAN from comment #17) > (In reply to Stas Sergeev from comment #15) > > (In reply to Stas Sergeev from comment #14) > > > Would you mind adding something like > > > NAME.en_US = Russian (legacy) > > > please? > > Or should it be just "legacy"? It seems "Russian" is > > appended from some other source. > > Yes, from > > ### Supported languages of this table > LANGUAGES = ru_RU > > This should probably only be "ru", not "ru_RU" (because > Russian is the same in RU and UA) > > > Then likely the following is needed: > > > > NAME.ru_RU = устаревшая > > NAME.en_US = legacy > > Trying ... https://github.com/moebiuscurve/ibus-table-others/releases/tag/1.3.5 https://github.com/moebiuscurve/ibus-table-others/commit/04f72fe38d399011801fe894971826a200ab64b4 https://admin.fedoraproject.org/updates/ibus-table-others-1.3.5-1.fc20 https://admin.fedoraproject.org/updates/ibus-table-others-1.3.5-1.fc19 Note that this needs ibus-table >= 1.9.1! (with ibus-table < 1.9.1 you will see only “rusle”, not “устаревшая”).
Thanks! > (with ibus-table < 1.9.1 you will see only “rusle”, not “устаревшая”). Not a big deal.
(In reply to Mike FABIAN from comment #16) > > (In reply to Mike FABIAN from comment #13) > > > I cannot reproduce this on F21 Alpha and I could not reproduce it on > > > F20 either so far. > > What exactly happens? > > You get RU at start-up and it works properly as RU? > > Yes. I get "ru" at start-up and it works properly. > > > Then it is specific to F19 somehow. > > Strange. Now I tried on a freshly installed F19 in qemu, I cannot reproduce it there either. "ru" is remembered but it works properly after start-up. No matter whether I log out of gnome and log in again in gdm or whether I do a full reboot, "ru" is used by default and works in both cases.
I am doing start-up from text mode, not gdm. Not sure if it makes any difference...
(In reply to Stas Sergeev from comment #23) > I am doing start-up from text mode, not gdm. > Not sure if it makes any difference... How exactly? “startx”?
Yes.
(In reply to Stas Sergeev from comment #21) > Thanks! > > > (with ibus-table < 1.9.1 you will see only “rusle”, not “устаревшая”). > Not a big deal. https://github.com/kaio/ibus-table/commit/616c93016c916d05555ad029768addfc12dbf548 https://github.com/kaio/ibus-table/releases/tag/1.9.1 https://admin.fedoraproject.org/updates/ibus-table-1.9.1-1.fc20 https://admin.fedoraproject.org/updates/ibus-table-1.9.1-1.fc19
(In reply to Stas Sergeev from comment #25) > Yes. Works for me as well when using startx from the console on f19. “ru” is remembered and works right away.
OK, I'll do more testings this evening. The new user I used yesterday was not exactly new: it already underwent a nearby bugreport where I was changing "grp" and a few other ibus options. I'll try really-really new user.
OK, seems like I've found a reliable way of reproducing this. mkdir ~/.config/imsettings ln -s /etc/X11/xinit/xinput.d/ibus.conf ~/.config/imsettings/xinputrc
OK, and I know who does this: im-chooser. Just select "ibus" in im-chooser and you get the bug at plate.
(In reply to Stas Sergeev from comment #29) > OK, seems like I've found a reliable way of > reproducing this. > > mkdir ~/.config/imsettings > ln -s /etc/X11/xinit/xinput.d/ibus.conf ~/.config/imsettings/xinputrc (In reply to Stas Sergeev from comment #30) > OK, and I know who does this: im-chooser. > Just select "ibus" in im-chooser and you get the bug at plate. Good that you found it! I can reproduce that on f19. On f21 Alpha it is not reproducible that easily because im-chooser and imsettings-switch refuse to run under Gnome on f21 Alpha. im-chooser and imsettings-switch are not supposed to be used under Gnome, only on the other desktops. And on f21 Alpha, this is properly checked.
Created attachment 942923 [details] im-chooser-and-imsettings-switch-should-not-run-under-gnome-f21.png Error message you see when you try to switch to IBus under Gnome in F21 Alpha.
(In reply to Mike FABIAN from comment #32) > Created attachment 942923 [details] > im-chooser-and-imsettings-switch-should-not-run-under-gnome-f21.png > > Error message you see when you try to switch to IBus under Gnome > in F21 Alpha. And this is the same under F20, im-chooser and imsettings-switch just refuse to run under Gnome.
So I don’t think we need to worry about this imsettings-switch and im-chooser problem because it is fixed already on f20 and f21.
I also checked on f20 that when one uses some other desktop (I used XFCE) and runs im-chooser (which creates the ~/.config/imsettings/xinputrc link) and then returns to Gnome this does not cause any problems. Even if that link exists, the input method is started correctly under Gnome in f20 and it works right away.
Hmm, in that case I'd say the underlying problem is fixed, but the fact that after "ibus restart" it still doesn't work, makes me suspicious... Anyway, the use-case appeared moot. Lets say that the bug is with "ibus restart" only then. It is still the run-time problem because after ibus update, the "ibus restart" may be executed AFAIK.
(In reply to Mike FABIAN from comment #32) > Created attachment 942923 [details] > im-chooser-and-imsettings-switch-should-not-run-under-gnome-f21.png Oh c'mon, the best example of user-friendly error message huh...
(In reply to Stas Sergeev from comment #36) > Lets say that the bug is with "ibus restart" only then. > It is still the run-time problem because after ibus > update, the "ibus restart" may be executed AFAIK. It doesn't. As I said, ibus-daemon is not supposed to be restarted under any circumstances in normal usage. I'm closing this bug.
How come is this not a bug? It was confirmed against F19!
> Lets say that the bug is with "ibus restart" only then. By this I mean "on anything above F19", while in F19 the bug is real.
(In reply to Stas Sergeev from comment #39) > How come is this not a bug? > It was confirmed against F19! The same problem exists on f20 and f21. But, as Rui says, this should not occur during normal usage because a normal user should not call “ibus restart”. After updating ibus packages this is of course necessary, but a “normal” user should probably reboot after updating packages. Developers of ibus engines of course use “ibus restart” all the time to test changes, but developers are not “normal” either.
But Mike, haven't you confirmed this bug on F19 _without_ "ibus restart"?
(In reply to Stas Sergeev from comment #42) > But Mike, haven't you confirmed this bug on > F19 _without_ "ibus restart"? *Only* if the link ~/.config/imsettings/xinputrc exists. See comment#31.
But the link is created by im-chooser, which is not "fixed" to not work under gnome. And even if it is, you can still run it under xfce and switch back, or you can get it from the online upgrade from prev fedora version. So I still don't see how is this not a bug under F19.
(In reply to Stas Sergeev from comment #44) > But the link is created by im-chooser, which > is not "fixed" to not work under gnome. > And even if it is, you can still run it under > xfce and switch back, or you can get it from > the online upgrade from prev fedora version. > So I still don't see how is this not a bug > under F19. On f20 and f21, it does not matter when you run im-chooser under xfce and switch back. The link exists then, but it does not cause any harm on f20 and f21, the link is properly ignored when Gnome is running on f20 and f21. Therefore, if that link happens to remain when you do an upgrade from f19 -> f20 or f21, it does not cause problems.
(In reply to Mike FABIAN from comment #45) > On f20 and f21, it does not matter when you Mike, I am only saying this is a bug on F19. I am not saying it is a bug on 20/21. On F19 it is a perfectly valid bug, so why NOTABUG?
(In reply to Stas Sergeev from comment #46) > (In reply to Mike FABIAN from comment #45) > > On f20 and f21, it does not matter when you > Mike, I am only saying this is a bug on F19. > I am not saying it is a bug on 20/21. > On F19 it is a perfectly valid bug, so why > NOTABUG? See comment#4. It is a Gnome bug, on f19, f20, and f21. But it is unlikely to be fixed any time soon not even for f20 and f21. So there is no chance that this will be fixed for f19. *If* it were something which could occur during normal use, there might be more motivation to fix it. But “ibus restart” (which is the only way to cause the problem on f20 and f21) does not count as normal use. This is something expert users do from time to time while testing and developing ibus, but “normal” users should not need it. So this is not nice, but not very high priority to fix. On f19 it is somewhat worse because it can happen by switching between xfce and gnome or playing under gnome with im-chooser but even that is kind of a remote corner case.