GNOME Bugzilla – Bug 684874
no ibus engines listed on the input sources chooser
Last modified: 2012-11-01 10:57:20 UTC
I am not sure what component is correct here. 1) start "User Accounts" in gnome-control-center in English locale 2) create a new user 3) assign any language say "Marathi" 4) logout and login to this new user 5) try to search for "Marathi" no keymaps found note actually this is a different bug. Irrespective of how am I searching (in English or in Marathi), what I found there is no m17n layout loaded at all. LANG=mr_IN.utf8 is correct set. Desktop is also in Marathi but no Marathi m17n keymap available.
Does it show up after gsettings set org.gnome.desktop.input-sources show-all-source true ?
I tried 3 different users to reproduce above. It got reproduced successfully. I also got some more things. 1) start "User Accounts" in gnome-control-center in English locale 2) create a new user 3) assign any language say "Marathi" 4) logout and login to this new user 5) run "ibus list-engine" command and output will be "Can't connect IBus" 6) go to choose input-source Marathi ibus engines 7) you will find no Marathi ibus engines 8) run "ibus list-engine". this will work now and even show Marathi ibus engines. 9) but still input-source Add dialog will not show you ibus engines. 10) close input-source tab and again open it for selection you will see now ibus engines why can't user see ibus engines first time its run?
Further testing in English locale only shows 1) create new user 2) login to that user 3) open input-sources 4) then click on + to add layouts You will find only xkb layouts but no ibus engines. If you wait a minute on step 3 and then proceed with step 4, then you can see ibus engines also. In summary, ibus takes some time to start. Can this time be utilized by adding some message dialog like "Enabling ibus..."? This way when user closes this dialog, clicking on + will give you ibus engines also.
(In reply to comment #3) > Further testing in English locale only shows > > 1) create new user > 2) login to that user > 3) open input-sources > 4) then click on + to add layouts > > You will find only xkb layouts but no ibus engines. > > If you wait a minute on step 3 and then proceed with step 4, then you can see > ibus engines also. Right, so I don't know why ibus-daemon is taking so long on your system but we are not indeed updating the input chooser's list when it becomes available which is a bug. Patch coming. > In summary, ibus takes some time to start. Can this time be utilized by adding > some message dialog like "Enabling ibus..."? This way when user closes this > dialog, clicking on + will give you ibus engines also. I'm afraid we can't change the UI at this point. Also, it can be considered a bug in IBus that it takes so long to start up although in my experience, even on a crappy slow 5400rpm HDD and deleting the ibus registry.xml file it doesn't take 1 minute to come up. Some seconds yes but 1 minute is way too long. What kind of system are you testing on?
Created attachment 225390 [details] [review] region: Repopulate input sources chooser when IBus becomes available Otherwise the IBus sources wouldn't be available in the chooser until it was closed and re-opened.
Looks reasonable to me, but I wonder if we need to be even more dynamic than this - there's currently no code to reload ibus_engines ever, right ? Does reopening the region panel cause it to reload ibus_engines ? Just wondering if we want to support the case of: user finds an input method missing, goes to terminal and installs it, then goes back to control-center.
(In reply to comment #4) > (In reply to comment #3) > > Further testing in English locale only shows > > > > 1) create new user > > 2) login to that user > > 3) open input-sources > > 4) then click on + to add layouts > > > > You will find only xkb layouts but no ibus engines. > > > > If you wait a minute on step 3 and then proceed with step 4, then you can see > > ibus engines also. > > Right, so I don't know why ibus-daemon is taking so long on your system but we > are not indeed updating the input chooser's list when it becomes available > which is a bug. Patch coming. > > > In summary, ibus takes some time to start. Can this time be utilized by adding > > some message dialog like "Enabling ibus..."? This way when user closes this > > dialog, clicking on + will give you ibus engines also. > > I'm afraid we can't change the UI at this point. Also, it can be considered a > bug in IBus that it takes so long to start up although in my experience, even > on a crappy slow 5400rpm HDD and deleting the ibus registry.xml file it doesn't > take 1 minute to come up. Some seconds yes but 1 minute is way too long. What > kind of system are you testing on? I am using Lenovo T410 and tested this bug under F18 VM
(In reply to comment #6) > Looks reasonable to me, but I wonder if we need to be even more dynamic than > this - there's currently no code to reload ibus_engines ever, right ? Does > reopening the region panel cause it to reload ibus_engines ? Just wondering if > we want to support the case of: user finds an input method missing, goes to > terminal and installs it, then goes back to control-center. That's true. Unfortunately ibus-daemon would need to reload itself for that to work which it currently doesn't do. I've filed a bug upstream to track that: http://code.google.com/p/ibus/issues/detail?id=1514
Review of attachment 225390 [details] [review]: Do we hide the IBus sources if IBus crashes? If not, do we have any guards against populating the sources list multiple times?
Just to make things clearer. There's 2 lists here, one is the active sources list which is displayed in the panel and consists of the sources that the user is able to switch among. The other list contains everything that's not on the previous one and is only created when the input sources chooser dialog is brought up. The ibus engines descriptions are gathered asynchronously on panel init and from then on we don't update them again (until the panel is entered again at least). (In reply to comment #9) > Do we hide the IBus sources if IBus crashes? If not, do we have any guards > against populating the sources list multiple times? Given the above, no we don't hide the ibus sources if the daemon crashes but we don't ever add duplicate entries to either of the lists. The panel list is populated on panel init and updated to show any ibus sources when the ibus engines are fetched and also when the 'sources' gsetting changes. The chooser list is created when the dialog is created and then cleared and repopulated if the ibus engines happen to show up only after is was created (it's what this patch now implements).
Review of attachment 225390 [details] [review]: Given the above, looks fine by me then.
Attachment 225390 [details] pushed as c767701 - region: Repopulate input sources chooser when IBus becomes available
I still see a noticeable delay of seconds before ibus sources appear in control-center. This is with Fedora 18 Beta (pre) and control-center-3.6.2.
Update:- I am still seeing this issue. I installed Fedora Beta TC6 and first time I try to use input-sources, there was no m17n engines. I just keep looking engines and suddenly they appeared as if list got refreshed. Ibus engines should be available at the same time xkb engines are shown in that list.
does this delay only happen right after login, or the first time you open the region panel, regardless how long the session has been going ?
The first time I open the region panel. I installed F18 Beta TC6 and then updated the system and rebooted it 2 times and then I went on configuring ibus engines first time. Problem still exist.
ok, so ibus was not running before you opened the region panel, because input methods were not configured yet. In that case, what you are seeing is slow startup of ibus, not a control-center issue. To confirm, can you start ibus manually before opening the region panel, and see if that makes input methods appear right away ?
I'm not sure we can do much better here. IBus just takes a long time to start up, especially on a clean user account because it has to go through all the installed engines to create its cache file ~/.cache/ibus/bus/registry.xml . To make matters worse, several engines' descriptions are created dynamically[1]. This requires the ibus-daemon to fork external processes, some of them written in python... I guess that a possible fix would be to make the ibus registry be built at package installation time and stored in a system wide location. We could also consider adding a small spinner in the control center panel while we don't get the answer from ibus although I really dislike this. [1] all of these on a default f18 install: $ grep \\-xml /usr/share/ibus/component/* /usr/share/ibus/component/anthy.xml: <engines exec="/usr/libexec/ibus-engine-anthy --xml" /> /usr/share/ibus/component/m17n.xml: <engines exec="/usr/libexec/ibus-engine-m17n --xml" /> /usr/share/ibus/component/simple.xml: <engines exec="/usr/libexec/ibus-engine-simple --xml" /> /usr/share/ibus/component/table.xml: <engines exec='/usr/libexec/ibus-engine-table --xml'/> /usr/share/ibus/component/typing-booster.xml: <engines exec='/usr/libexec/ibus-engine-typing-booster --xml'/>
But when users launch g-c-c, $HOME/.cache/ibus/bus/registry.xml has been already generated. I think it's a bug in g-c-c while I don't see the problem in ibus + ibus gtk panel. I think g-c-c does not show the latest engines for more than five minutes while the cache file is generated for 20 seconds.
I decided to measure it roughly with a small script, which I tested on F18 Beta (pre) Live (x86_64) with a Lenovo T500 (8GB). Steps: 1. boot F18 Beta Desktop Live image 2. start default Live User gnome session (ie in en_US.utf8) 3. open gnome-terminal $ cat > test.sh gnome-control-center region & CACHE=$HOME/.cache/ibus/bus/registry.xml date +%S.%N while [ ! -f $CACHE ]; do echo -n . usleep 100000 done echo tail $CACHE date +%S.%N $ sh test.sh which shows that it takes about 5s on my machine from launching the Region panel until the ibus registry.xml file is ready. (In reply to comment #19) > But when users launch g-c-c, $HOME/.cache/ibus/bus/registry.xml has been > already generated. Right that is true for a ja_JP.utf8 session, but not for en_US.utf8.