After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 688916 - Remove Input Source Indicator's Property White List
Remove Input Source Indicator's Property White List
Status: RESOLVED DUPLICATE of bug 682318
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-11-23 06:56 UTC by Ma Hsiao-chun
Modified: 2012-11-24 17:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ma Hsiao-chun 2012-11-23 06:56:46 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.
Comment 1 Bastien Nocera 2012-11-23 07:12:22 UTC
(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.
Comment 2 Ma Hsiao-chun 2012-11-23 08:21:13 UTC
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.
Comment 3 Ma Hsiao-chun 2012-11-24 07:50:49 UTC
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. )
Comment 4 Mike Qin 2012-11-24 13:43:16 UTC
(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!
Comment 5 Jasper St. Pierre (not reading bugmail) 2012-11-24 15:03:42 UTC
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 ***
Comment 6 Mike Qin 2012-11-24 16:27:03 UTC
(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.
Comment 7 Ma Hsiao-chun 2012-11-24 16:58:13 UTC
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.
Comment 8 Mike Qin 2012-11-24 17:14:04 UTC
(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.