Steps to Reproduce: 1. Install fresh Fedora 18 2. yum update 3. Install any of the following packages: ibus-handwrite ibus-input-pad ibus-sunpinyin ibus-table-chinese-array ibus-table-chinese-cantonese ibus-table-chinese-easy ibus-table-chinese-scj ibus-table-chinese-wu ibus-table-chinese-wubi-haifeng ibus-table-chinese-wubi-jidian ibus-table-chinese-yong ibus-table-mathwriter ... 4. ibus-daemon -drx [*] 5. Check input source list Actual results: Nothing changed Expected results: New engine appear Additional info: * This is command is old school; 'ibus restart' probably work also. I never tried that, though.
gsettings set org.gnome.desktop.input-sources show-all-sources true PS: Unlucky, it's the same people upstream and downstream.
I feel like I'm missing something here. It sounds like the bug is that you can't add input methods post-install yet the state is CLOSED WONTFIX. Am I understanding correctly or am I misunderstanding some details?
(In reply to comment #2) > I feel like I'm missing something here. It sounds like the bug is that you > can't add input methods post-install yet the state is CLOSED WONTFIX. Am I > understanding correctly or am I misunderstanding some details? You're missing Ma being a jerk downstream about that same subject. The bug that's being hinted at above is that we do whitelisting of input sources. We won't change that, however annoying the reporter gets.
In case anyone else gets pulled into this, I figure I'll describe what's going on a bit more. The issue started upstream with https://bugzilla.gnome.org/show_bug.cgi?id=688914 Gnome has implemented a whitelist of which input methods are allowed and which are not. This whitelist did not exist for gnome in F17. The input methods mentioned in comment#1 are not on this whitelist. If a user installs the input methods, expecting them to show up in gnome or upgrades from F17 with the input methods installed, there is apparently not much of an error message describing why they won't show up. I agree with Ma that this doesn't seem to be the most user friendly thing ever if these input methods worked in F17 but I also don't pretend to understand much about how input methods work or why the whitelist was implemented so my opinion on this isn't very valuble.
> gsettings set org.gnome.desktop.input-sources show-all-sources true 1. This step is not really intuitive to non-technical users. 2. After set so, ibus shows installed input methods, as well as all supported keyboard layouts, which are not so feasible. The reporter might be immature, but maintaining the white list in Gnome add extra effort to the developer team (to keep the list up-to-date and deploy it), the support team (to document the change and process and answer questions), and end-users, especially the ones who are not good at English (they cannot search for solution using their own language). As this bug actually affect quite a good deal of input method users, I hereby reopen the bug and hope this issue to be addressed.
I'm not going to change GNOME software in Fedora.
You may want to check how Bastien Nocera's masterpiece is documented in Release Notes of Fedora 18. http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/sect-Release_Notes-Changes_for_Desktop.html#idm1289072 """ If you can't find an input source you are looking for in the list, try running the following command in a terminal and restart the desktop: gsettings set org.gnome.desktop.input-sources show-all-sources true """ It sounds like a bug rather than a feature, unfortunately.
Seriously, if lots of people need to use gsettings set org.gnome.desktop.input-sources show-all-sources true to get around the white-list to get to their input methods. What's the point to implement the white-list in the first place?
(In reply to comment #7) > You may want to check how Bastien Nocera's masterpiece is documented in > Release Notes of Fedora 18. Personal attacks? How nice.
Masterpiece means chef d'oeuvre or "a work done with extraordinary skill; especially : a supreme intellectual or artistic achievement" (Merriam-Webster), merci beaucoup.
(In reply to comment #10) > Masterpiece means chef d'oeuvre or "a work done with extraordinary skill; > especially : a supreme intellectual or artistic achievement" > (Merriam-Webster), merci beaucoup. It's not the words, it's the tone and the fact that you keep on reopening a bug that I said we would not patch downstream. If you wanted to be annoying, you couldn't have done it better. Quit it.
> It's not the words, it's the tone and the fact that you keep on reopening a bug that I said we would not patch downstream. There are at least two Red Hat guy here. One guy is a spammer that never respond to the real problem here. Quotes: "PS: Unlucky, it's the same people upstream and downstream." "You're missing Ma being a jerk downstream about that same subject. The bug that's being hinted at above is that we do whitelisting of input sources. We won't change that, however annoying the reporter gets." "Personal attacks? How nice." This guy want to close this bug. Another guy sees the real problem and want to open this bug. I support the later guy however annoying the spammer gets. BTW, I'm not aware of tone stuff in English. http://en.wikipedia.org/wiki/Tone_%28linguistics%29 I pointed out the UX issue, the docs issue. I won't quit until the issues are resolved. The guy created the issues and tried hard to undermine resolving effort deserves blaming.
I think we have now option to enable all installed input sources in GUI application gnome-tweak-tool. Just run it, select left Typing and on right side a switch to ON/OFF for showing all non-whitelisted engines also. I am not sure why this usage of gnome-tweak-tool is not documented in the link given in comment#7 Hope this helps as upstream is not going to get changed.
In docs, we have to answer: Why some useful, already packaged input engines are filtered out by default? Why a tweak is needed, just to show all input sources in an ugly manner (There will be many duplicates in the input sources list, I can give screen shots)? Having it in gnome-tweak-tool mitigates the whole problem a little bit but not much, unless we assume every GNOME users tweak. Regarding release notes, if it documents gnome-tweak-tool instead, then: It should include how to install gnome-tweak-tool, which is one yum command or some lengthy text of gnome-packagekit. (Is such information already included in other places?) It should include lengthy text of gnome-tweak-tool itself. It still sounds like a bug not fixed. So I don't think it will be better than current state.
BTW, in a corporate, multi-user environment, do we expect local admins provide dconf-editor or gnome-tweak-tool to end users? gsettings(1) seems to be the tool to use in that case. Yes, local admins can preset that gsettings key to show all input sources. But as I mentioned, the input sources list won't look pleasant because there are many duplicates.
(In reply to comment #14) Ma Xiajun, comment#14> Why a tweak is needed, just to show all input Ma Xiajun, comment#14> sources in an ugly manner (There will be many Ma Xiajun, comment#14> duplicates in the input sources list, I can Ma Xiajun, comment#14> give screen shots)? Yes, there are extremely many duplicates in the input sources list. I reported a but about this a while ago: https://bugzilla.redhat.com/show_bug.cgi?id=869117
(In reply to comment #12) > > It's not the words, it's the tone and the fact that you keep on reopening a bug that I said we would not patch downstream. > > There are at least two Red Hat guy here. > > One guy is a spammer that never respond to the real problem here. Quotes: > "PS: Unlucky, it's the same people upstream and downstream." > "You're missing Ma being a jerk downstream about that same subject. The bug > that's being hinted at above is that we do whitelisting of input sources. We > won't change that, however annoying the reporter gets." > "Personal attacks? How nice." > This guy want to close this bug. > > Another guy sees the real problem and want to open this bug. > > I support the later guy however annoying the spammer gets. > > BTW, I'm not aware of tone stuff in English. > http://en.wikipedia.org/wiki/Tone_%28linguistics%29 > > I pointed out the UX issue, the docs issue. > I won't quit until the issues are resolved. > The guy created the issues and tried hard to undermine resolving effort > deserves blaming. Ma, I maybe wrong, but using sarcasm is not the best way to reach consensus. This is a technique issue and should be addressed and discussed as one.
(In reply to comment #13) > I think we have now option to enable all installed input sources in GUI > application gnome-tweak-tool. Just run it, select left Typing and on right > side a switch to ON/OFF for showing all non-whitelisted engines also. > > I am not sure why this usage of gnome-tweak-tool is not documented in the > link given in comment#7 > > Hope this helps as upstream is not going to get changed. Only 3 out of 12 of ibus-table-chinese subpackages are in the whitelisted. It is very strange that you have to manually switch a switch to actually see what you have explicitly installed. In other words, if your favourite input method is not in the whitelist, then from default install, you now have to do following 1. Install the input method 2. Install gnome-tweak-tool 3. Set org.gnome.desktop.input-sources show-all-sources true 4. Find and activate your input methods from the long list Step 2 and 3 are not need without whitelist implementation.
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.
I believe this is okay now in F19+.