Hide Forgot
Description of problem: Not sure if it is ibus or ibus-anthy but at least ibus-anthy these days often seems very slow to activate/turn on. Steps to Reproduce: 1. Activate ibus-anthy for first time in session say 2. start typing immediately Actual results: ibus-anthy takes some seconds to activate - often resulting in my first input not getting converted at all: eg just now I wanted to write "ありがとう”but actual input was "ariがとう"... Expected results: "ありがとう" and ibus-anthy to activate immediately. Ueno-san mentioned to me in another context that it might be loading of ibus-anthy config that is the bottleneck. Additional info: This seems like a regression but maybe it is related to upstream ibus not supporting preloading of IMEs? Anyway not really sure why ibus-anthy should take so long to start up.
I sometimes see similar delay on mozc too. so I guess it maybe not ibus-anthy specific.
from my experience of ibus-skk, using ibus_config_get_values() instead of calling _get_value() for each config item reduced startup time drastically. just tried it a bit with ibus-anthy: diff --git a/setup/prefs.py b/setup/prefs.py index eff483b..f3ca553 100644 --- a/setup/prefs.py +++ b/setup/prefs.py @@ -115,8 +115,10 @@ class Prefs(object): self.fetch_section(s) def fetch_section(self, section): - for k in self.keys(section): - self.fetch_item(section, k) + values = self._config.get_values (section) + for key in values.keys(): + v = variant_to_value(values[key]) + self.modified.setdefault(section, {})[k] = v if v != [''] else [] and it actually seems to help.
(In reply to comment #2) > from my experience of ibus-skk, using ibus_config_get_values() instead of > calling _get_value() for each config item reduced startup time drastically. Thanks for the info. I integrated it but it seems before is 4-5 sec and after is 3 sec in my test. https://github.com/fujiwarat/ibus-anthy/commit/df2d57feb47175bd21615ebbcd5bd0956f9486f9 I'm not sure if this could resolve the submitter's problem but probably it's good to ask the test. AFAIK, the problem can be reproduced when reboot the system and log in the session and switch to a python engine.
ibus-anthy-1.4.99.20121006-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/ibus-anthy-1.4.99.20121006-1.fc18
ibus-anthy-1.4.99.20121006-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/ibus-anthy-1.4.99.20121006-1.fc17
Package ibus-anthy-1.4.99.20121006-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ibus-anthy-1.4.99.20121006-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-15532/ibus-anthy-1.4.99.20121006-1.fc18 then log in and leave karma (feedback).
ibus-anthy-1.4.99.20121006-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I think this is still happening for F17 and probably also F18.
I'm having the same problem with mozc. This + bug 871482 combined is a big source of frustration. ibus-mozc-1.6.1187.102-2.fc18.x86_64
It turned out that the real culprit (for me at least) is gnome-settings-daemon which triggers input source switch on key release instead of press. The behavior is pointed out in a comment of bug 871482. The symptom I had is: 1. Hit ibus hot key to switch to ibus-mozc. 2. start typing 3. the expected japanese inline input session does not start immediately and an alphabet character appears at the caret instead. 4. this lead me to believe that I failed to trigger the hot key 5. Hit ibus hot key again to switch to ibus-mozc. 6. ibus switches to the english input source. 7. start typing and an alphabet char appears again 8. go back to step #1. I tweaked the gnome-settings-daemon and the symptom has gone. It is still present when I switch to ibus-mozc by selecting it from the gnome-shell menu though. +++ bug 871482 leads to https://bugzilla.gnome.org/show_bug.cgi?id=693747
I will address only the performance before the IME is launched in this bug. You could check 'ps -ef | grep ibus-engine-foo'. https://bugzilla.gnome.org/show_bug.cgi?id=695428 ibus 1.5 check the release event because now new switcher GUI is integrated. gnome-shell also implement the similar GUI in f19 but probably I don't think it will be back port to f18. It would be nice if you could check ibus-1.5.1-3.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
*** This bug has been marked as a duplicate of bug 1133283 ***