Description of problem: ibus can consistently lose all preferences on deselecting "Customize active input methods" and restart. Version-Release number of selected component (if applicable): ibus-1.3.99.20110419-1.fc15.x86_64 How reproducible: Always Steps to Reproduce: 1. select "Customize active input methods" to allow adding to the input method list 2. adding a whole bunch of chinese input methods (the 4 Cangjie's, and a few others) 3. unselecting "Customize active input methods" 4. The input methods are available 5. Now choose to restart ibus Actual results: All input methods selected lost Expected results: Input methods user selected preserved across session Additional info: ibus also seems to periodically lose user input method preference from time to time. Not too sure about what's the purpose of the "Customize active input methods" checkbox - presumably anybody who invoke the preference panel intends to modify the method list, since viewing is available just from the main panel. So a checkbox which presumably limits it to viewing seems to be redundant. OTOH, if the checkbox means *enable* input methods, the wording is very misleading.
Probably it's a wording issue. We may need to think the better sentence or adding the tooltip; "Customize active input methods". If the checkbox is disabled (by default), ibus always calculate the preloaded engines by login by locale. It's used for users who log into multiple locales. You could try to log into Chinese, Japanese desktop with the disabled checkbox.
The feature was integrated for the fix of bug 530711.
(In reply to comment #1) > Probably it's a wording issue. > We may need to think the better sentence or adding the tooltip; "Customize > active input methods". > > If the checkbox is disabled (by default), ibus always calculate the preloaded > engines by login by locale. It's used for users who log into multiple locales. > You could try to log into Chinese, Japanese desktop with the disabled checkbox. Okay, so by 'customize input methods', you really means 'enable the use of input methods not in your current locale'. No wonder I keep losing my preference. The way it is currently done a rather mis-feature and rather wrong. I use mainly an English (UK) environment but occasionally need to type Chinese. And I think even the preloading (at least for Chinese users for Chinese locale) is wrong - there are probably 20+ traditional chinese input methods but most people only uses <5, but it is a different 5 for a different person. Not installing some methods is out of the question for multi-user systems, but preloading 20 methods for each person who only uses about 5 (and a specific 5) seems wrong and troublesome, and a long list to scroll to switch between them.
(In reply to comment #3) > Okay, so by 'customize input methods', you really means 'enable the use of > input methods not in your current locale'. No wonder I keep losing my > preference. Enabling 'customize input methods' doesn't not lose your preference. It's disabled by default, which loses your preference but you could keep your preference once you enable it. > The way it is currently done a rather mis-feature and rather wrong. I use > mainly an English (UK) environment but occasionally need to type Chinese. So you could enable 'customize input methods' if you want to customize the input method list. I wonder if you understand the feature. > And I think even the preloading (at least for Chinese users for Chinese locale) > is wrong - there are probably 20+ traditional chinese input methods but most > people only uses <5, but it is a different 5 for a different person. Not You don't figure out this feature correctly. Preload engines doesn't mean to load all Chinese input methods. You could test the feature with a new user. It's a default setting for new users but you could customize the list.
(In reply to comment #4) > (In reply to comment #3) > > > Okay, so by 'customize input methods', you really means 'enable the use of > > input methods not in your current locale'. No wonder I keep losing my > > preference. > > Enabling 'customize input methods' doesn't not lose your preference. > It's disabled by default, which loses your preference but you could keep your > preference once you enable it. > > > The way it is currently done a rather mis-feature and rather wrong. I use > > mainly an English (UK) environment but occasionally need to type Chinese. > > So you could enable 'customize input methods' if you want to customize the > input method list. > I wonder if you understand the feature. > > > And I think even the preloading (at least for Chinese users for Chinese locale) > > is wrong - there are probably 20+ traditional chinese input methods but most > > people only uses <5, but it is a different 5 for a different person. Not > > You don't figure out this feature correctly. > Preload engines doesn't mean to load all Chinese input methods. > You could test the feature with a new user. > It's a default setting for new users but you could customize the list. I think I "understand" the feature, I just do not agree with it. At the moment (in UK English locale, and from what you said, very likely on US locale as well) there is none shown, and none selectable. To have any user-preferred (non-English) input method at all, one needs to click the check box, and choices remains until dbus restarts. This is confusing because: 1) preferences are only editable by clicking the check-box, and preferences does not disappear *immediately* on unchecking the ticked check-box, which suggests *wrongly* that the checkbox is required for *updating* the list. 2) there is no warning on unchecking the check-box that preferences will be lose (and be lose when ibus restarts or the user relog-in). Most importantly, I bet I am not the only person who choose to work primarily in a English desktop environment but have occasional non-English needs - I dare say my situation is probably in the majority (compared to chinese environment + choices of 5-ish familiar chinese input methods among 20+ input methods, or japanese environment + choice of a few input methods among a few). So I suggest: 1) there should be some tooltip or better worded indication of what the check-box is really for 2) there should be a warning about losing user preference if the user unchecks the checkbox.
(In reply to comment #5) > 1) preferences are only editable by clicking the check-box, and preferences > does not disappear *immediately* on unchecking the ticked check-box, which > suggests *wrongly* that the checkbox is required for *updating* the list. OK, I agree to update the list on unchecking the box. Previously I tried it but it would effect the ibus start up time during the login and caused dbus timeout. So I removed the updating function. Now ibus supports the async functions and probably the performance is ok with my test. I implemented it now. > So I suggest: > 1) there should be some tooltip or better worded indication of what the > check-box is really for > > 2) there should be a warning about losing user preference if the user unchecks > the checkbox. OK, probably the 2) would be enough for your request. Now I launch one dialog with: "The list of your saved input methods will be cleared immediately and the list will be configured by the login language every time. Do you agree with this?" https://github.com/fujiwarat/ibus/commit/874115071e9897435dd9a01e10f84d1c428ac36c
http://koji.fedoraproject.org/koji/buildinfo?buildID=249486
ibus-1.3.99.20110419-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/ibus-1.3.99.20110419-3.fc15
Package ibus-1.3.99.20110419-3.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ibus-1.3.99.20110419-3.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/ibus-1.3.99.20110419-3.fc15 then log in and leave karma (feedback).
Package ibus-1.3.99.20110419-5.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ibus-1.3.99.20110419-5.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/ibus-1.3.99.20110419-5.fc15 then log in and leave karma (feedback).
Created attachment 509869 [details] IBus Preferences in ibus-1.3.99.20110419-5.fc15. After updating to 1.3.99.20110419-5.fc15, Keyboard Shortcuts items(execpt Next Input method) are empty on IBus preferences.
(In reply to comment #11) > Created attachment 509869 [details] > IBus Preferences in ibus-1.3.99.20110419-5.fc15. > > After updating to 1.3.99.20110419-5.fc15, Keyboard Shortcuts items(execpt Next > Input method) are empty on IBus preferences. Yes, you're right. In this change, I moved ibus trigger keys to engine hotkeys. If you would add '<hotkeys>Hangul,Control+space<hotkeys> in /usr/share/ibus/component/hangul.xml and run 'ibus-daemon -r --xim -t refresh', you could enable ibus-hangle with Hangul key. http://desktopi18n.wordpress.com/2011/06/23/ibus-icon-symbol-property/ Probably I will replace 'icon_symbol' with 'symbol' and update ibus again later.
(In reply to comment #12) > (In reply to comment #11) > > Created attachment 509869 [details] > > IBus Preferences in ibus-1.3.99.20110419-5.fc15. > > > > After updating to 1.3.99.20110419-5.fc15, Keyboard Shortcuts items(execpt Next > > Input method) are empty on IBus preferences. > > Yes, you're right. > In this change, I moved ibus trigger keys to engine hotkeys. > If you would add '<hotkeys>Hangul,Control+space<hotkeys> in > /usr/share/ibus/component/hangul.xml and run 'ibus-daemon -r --xim -t refresh', > you could enable ibus-hangle with Hangul key. > > http://desktopi18n.wordpress.com/2011/06/23/ibus-icon-symbol-property/ > > Probably I will replace 'icon_symbol' with 'symbol' and update ibus again > later. Currently I'm thinking the following patch for each engine: http://pkgs.fedoraproject.org/gitweb/?p=ibus-anthy.git;a=commitdiff https://github.com/ueno/ibus-skk/commit/7f6a6bfe155b210bb4a3073cc38ca25c161f5623
Package ibus-1.3.99.20110419-6.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ibus-1.3.99.20110419-6.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/ibus-1.3.99.20110419-6.fc15 then log in and leave karma (feedback).
Package ibus-1.3.99.20110419-7.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ibus-1.3.99.20110419-7.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/ibus-1.3.99.20110419-7.fc15 then log in and leave karma (feedback).
sangu.fedora: Do you have any problems? The problem is fixed in my test.
(In reply to comment #16) > sangu.fedora: Do you have any problems? > The problem is fixed in my test. The same problem ( comment #11 ) still happens in 1.3.99.20110419-7.fc15.x86_64.
ibus-1.3.99.20110419-7.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #17) > The same problem ( comment #11 ) still happens in > 1.3.99.20110419-7.fc15.x86_64. As I noted in comment #12, shortcut keys are no longer handled by ibus but each ibus engine. If you'd like to add shortcut keys, you might need a bug for the specific engine (e.g. ibus-hangul) instead of ibus.