GNOME Bugzilla – Bug 688916
Remove Input Source Indicator's Property White List
Last modified: 2012-11-24 17:14:04 UTC
Commit hint: http://git.gnome.org/browse/gnome-shell/commit/?id=9659d934ac190a6363fc5b59f3c62ef305f56c52 Source code hint: http://git.gnome.org/browse/gnome-shell/tree/js/ui/status/keyboard.js#n188 The white list makes no sense. IBus engines have different properties to expose and the current while list works only for ibus-anthy. This means: 1. ibus-pinyin/ibus-libpinyin, ibus-chewing, ibus-table is handicapped, their properties are no longer visible. 2. According to its author, ibus-typing-booster already give up properties. 3. 'Third-party' engines will have their properties blocked unless they contact GNOME 'governors' to allocate a white list entry for them. GNOME Shell's input source indicator should do nothing special compare to IBus in other environments. If you feel that a particular IBus engine has UX problem in its property menu, please ask its upstream to resolve it.
(In reply to comment #0) > 3. 'Third-party' engines will have their properties blocked unless they contact > GNOME 'governors' to allocate a white list entry for them. To me that reads: IBus engine won't integrate unless they make the effort to integrate Which seems like a good reason to not change the whitelist.
You don't even understand what is exactly the issue. But, anyway, it is never the case that we integrate a engine or block it completely. The fact that you ship a decent engine by default doesn't mean that users don't want others.
Check the below videos for those who haven't extensive CJK inputting experience and don't understand what the issue really is. http://dl.dropbox.com/u/45139465/gnome34.webm http://dl.dropbox.com/u/45139465/gnome36.webm ( There is no sound/voice. )
(In reply to comment #1) > (In reply to comment #0) > > 3. 'Third-party' engines will have their properties blocked unless they contact > > GNOME 'governors' to allocate a white list entry for them. > > To me that reads: > IBus engine won't integrate unless they make the effort to integrate > > Which seems like a good reason to not change the whitelist. Are you sure you understand the issue? The issue is you're whitelist on the property list, and all CJK input method *is not working*. Take the video as an example, in Chinese users need modes like "English mode", "Full/Half Corner", "Ascii punctuation" and sometimes "Traditional Character Support" in mainland China. If you blacklist it, these modes Chinese input method will not work. These modes are *not* preferences, switching these modes back and forth are daily essential to input Chinese!
For now, this was done in 3.6 because of time pressure (we didn't have time to implement the entire generic system, so we implemented a few properties for anthy). The bug to remove the white list and implement the rest of the properties is #682318. There was no malice intended, and I'm sorry that you took it the wrong way. *** This bug has been marked as a duplicate of bug 682318 ***
(In reply to comment #5) > For now, this was done in 3.6 because of time pressure (we didn't have time to > implement the entire generic system, so we implemented a few properties for > anthy). The bug to remove the white list and implement the rest of the > properties is #682318. > > There was no malice intended, and I'm sorry that you took it the wrong way. > > *** This bug has been marked as a duplicate of bug 682318 *** I see. If this is a in-progress implementation, then we should work together on bug 682318. I'm going to move the videos links above to bug 682318 as well, and see if I can come up with a patch at some point. :) And of course, there's definitely no malice. The only thing that's making Chinese community angry is the attitude of "No, this will never happen" from a developer who don't know even how to type Chinese. Of course, not in this case.
Hi, Jasper St. Pierre But I still feel like you probably misunderstand the ecosystem and history of IBus and IBus engines. I encourage to check another video recorded by me early on Ubuntu 12.10 with vanilla IBus 1.4.2 for other purpose. http://dl.dropbox.com/u/45139465/vanilla-ibus.ogv Some background: In 1.4, 1.3, 1.2 days, we both tray icon menu (in the video when I set 'Embedded in menu', similar to OS X) and language panel (in the video when I set 'Always', similar to Windows) to display properties. Language panel should be more popular, ibus-table doesn't bother to set text label at all for a very long time. Until Fedora 17 people (re-)discovered this problem since language panel is dropped. And you should note that there are color icons associated with properties (again, similar to Windows). So people care less about the clarity of text labels. But now we only have text labels. So what? You are not going to implement any properties. They are already there and working. What you should do is that asking the engines to polish their text labels because: 1. They may not be clear enough, since there was associated color icon as a hint. 2. They may be inconsistent between engines. I can understand you have limited resource. But the result of partial work should be technical limitations rather than arbitrary limitations. For example, you can stay in a state that some property type is not supported, that's natural. But a state that only certain anthy properties are white listed but all other engines' existing properties are unusable are definitely annoying for end users.
(In reply to comment #7) > Hi, Jasper St. Pierre > > But I still feel like you probably misunderstand the ecosystem and history of > IBus and IBus engines. > > I encourage to check another video recorded by me early on Ubuntu 12.10 with > vanilla IBus 1.4.2 for other purpose. > http://dl.dropbox.com/u/45139465/vanilla-ibus.ogv > > Some background: > In 1.4, 1.3, 1.2 days, we both tray icon menu (in the video when I set > 'Embedded in menu', similar to OS X) and language panel (in the video when I > set 'Always', similar to Windows) to display properties. > Language panel should be more popular, ibus-table doesn't bother to set text > label at all for a very long time. Until Fedora 17 people (re-)discovered this > problem since language panel is dropped. > And you should note that there are color icons associated with properties > (again, similar to Windows). So people care less about the clarity of text > labels. But now we only have text labels. > > So what? You are not going to implement any properties. They are already there > and working. What you should do is that asking the engines to polish their text > labels because: > 1. They may not be clear enough, since there was associated color icon as a > hint. > 2. They may be inconsistent between engines. > > I can understand you have limited resource. But the result of partial work > should be technical limitations rather than arbitrary limitations. For example, > you can stay in a state that some property type is not supported, that's > natural. But a state that only certain anthy properties are white listed but > all other engines' existing properties are unusable are definitely annoying for > end users. Don't worry. I'm working on the bug 682318 impact on this bug now. I'll see if I can come up with a solution though.