GNOME Bugzilla – Bug 688914
Change Input Source Filtering to Black List
Last modified: 2013-01-14 03:19:04 UTC
Source code hint: http://git.gnome.org/browse/gnome-control-center/tree/panels/region/gnome-region-panel-input.c#n67 http://git.gnome.org/browse/gnome-control-center/tree/panels/region/gnome-region-panel-input.c#n438 Currently we are using white list approach. That's problematic because: 1. Some existing, useful IBus engines are not included. Users may install them and note that nothing appear in input source list. Example: http://code.google.com/p/rimeime/ http://code.google.com/p/sunpinyin/ http://code.google.com/p/libgooglepinyin/ http://code.google.com/p/ibus-cloud-pinyin/ ( This one is outdated, it will may revive though. ) http://code.google.com/p/ibus-t9/ ( I'm not sure about the current state of this one. ) 2. ibus-table and ibus-m17n allow creation of customized engine, however, these engines won't appear in input source list, either. Example: http://code.google.com/p/ibus/issues/detail?id=1544 I do understand that some input sources may merely cause confusion and do no good. So we black list them, that is the right way to do it.
As discussed on the mailing-list, and until further developments, that won't happen. I'm not adding "outdated" and "unknown state" engines.
There is never ever a system that has that hostile attitudes towards third-party engines. From this aspect. * Android is open. * Mac OS X is open. * Windows is open. * But GNOME is proprietary. And what about reason 2, do you need to re-read it?
I am not familiar with Chinese input methods but there is a problem I see with a whitelist approach. GNOME is currently scheduled to release twice a year. Assume a new wonderful input method was developed during the 3.5 phase but it was deemed too late for a change (freeze in effect). So it did not make it into 3.6. It's August 2012. Instead it was committed as one of the first changes in 3.7 and finally made it to a stable 3.8 release. The tarballs are there for distros to pick and we're nearing end of March 2013. But it so happened that Fedora 18 slipped so much it only got released in January. Work on shaping Rawhide into a F19 release has only started and an alpha release is expected to appear in June. This means a stable release reaching its users in July or August 2013. So unless we plan to manage the whitelist as a separate package that is released on-demand (like tzdata) instead of following GNOME's schedule I don't think the whitelist is beneficial to users no matter which languages they use. As for Chinese: to understand the problem it would be interesting to see the differences between different input methods. Like the sequences of keys one has to press to input different phrases and what constitutes their strong and weak sides? Also if it's possible at all to combine all the good parts to build an über-solution or if some of them are conflicting with each other.
(In reply to comment #3) > I am not familiar with Chinese input methods but there is a problem I see with > a whitelist approach. <snip> > So unless we plan to manage the whitelist as a separate package that is > released on-demand (like tzdata) instead of following GNOME's schedule I don't > think the whitelist is beneficial to users no matter which languages they use. Using a blacklist would mean that we have the same problems, without any input into the final user's experience. We cannot know all the IM engines that exist, so can't blacklist the ones we don't know about. As for the maintainability, it's open source, and we can add one-liners in gnome-control-center after hard freezes, and so can downstream distributors. A blacklist is effectively worse than a whitelist for that case. > As for Chinese: to understand the problem it would be interesting to see the > differences between different input methods. Like the sequences of keys one has > to press to input different phrases and what constitutes their strong and weak > sides? Also if it's possible at all to combine all the good parts to build an > über-solution or if some of them are conflicting with each other. That's what Mathieu and others have been trying to do: http://bochecha.fedorapeople.org/chinese_ims/ https://live.gnome.org/InputCJK
(In reply to comment #4) > Using a blacklist would mean that we have the same problems, without any input > into the final user's experience. We cannot know all the IM engines that exist, > so can't blacklist the ones we don't know about. As for the maintainability, > it's open source, and we can add one-liners in gnome-control-center after hard > freezes, and so can downstream distributors. A blacklist is effectively worse > than a whitelist for that case. Yes the blacklist would be at least equally bad. I am just wondering whether it's worth the effort to filter the list at all. It's not like Fedora, Ubuntu, GNOME OS or whatever else will come with a thousand IBus plugins preinstalled. With things like wallpapers and themes the preferred method is to just ship the usable ones but there's not mechanism in place that stops the user from installing a theme that only consists of shades of pink.
(In reply to comment #5) > Yes the blacklist would be at least equally bad. I am just wondering whether > it's worth the effort to filter the list at all. It's not like Fedora, Ubuntu, > GNOME OS or whatever else will come with a thousand IBus plugins preinstalled. Default F18 install: shown 95 hidden 777 And that's just IBus engines. > With things like wallpapers and themes the preferred method is to just ship the > usable ones but there's not mechanism in place that stops the user from > installing a theme that only consists of shades of pink. But we don't ship a pink one by default, or stop people from customising it by poking at GSettings, just like in the IBus case.
(In reply to comment #6) > Default F18 install: > shown 95 > hidden 777 > > And that's just IBus engines. Sure but would you recommend shipping the 777? It's much easier for Fedora to change their default install than for GNOME to track the ever-changing list of existing plugins. I don't see how IBus engines are different from GStreamer plugins, GTK+ modules or Xorg drivers. If a standard API and a well-defined plugin point exists, solving the software quality problem lays well outside of GNOME's scope (treating GNOME as a platform, hypothetical GNOME OS should just ship a very limited list of IMs in its default install).
(In reply to comment #7) > Sure but would you recommend shipping the 777? It's much easier for Fedora to > change their default install than for GNOME to track the ever-changing list of > existing plugins. It's only 6 different packages, and each one of those contains useful engines. > I don't see how IBus engines are different from GStreamer plugins, GTK+ modules > or Xorg drivers. The GStreamer plugins and Xorg drivers aren't user visible. I don't put them in a list for the user to choose. The IBus engines are all listed when you add a new input source. I don't think that having 200 different engines marked "Chinese" is going to help users.
(In reply to comment #8) > It's only 6 different packages, and each one of those contains useful engines. Ouch. Can these be safely split to only install the really useful ones? > The IBus engines are all listed when you add a > new input source. I don't think that having 200 different engines marked > "Chinese" is going to help users. I wholeheartedly agree that having to choose from a list of hundreds of seemingly identical options is suboptimal but I see no reason to package the hundreds in the first place. If we cut the list of installed by default down to three or so useful methods for Chinese then GNOME could have a preferred one but allow the user to choose anything that is installed even if the user chooses to install fifty more.
(In reply to comment #9) > (In reply to comment #8) > > It's only 6 different packages, and each one of those contains useful engines. > > Ouch. Can these be safely split to only install the really useful ones? > > > The IBus engines are all listed when you add a > > new input source. I don't think that having 200 different engines marked > > "Chinese" is going to help users. > > I wholeheartedly agree that having to choose from a list of hundreds of > seemingly identical options is suboptimal but I see no reason to package the > hundreds in the first place. If we cut the list of installed by default down to > three or so useful methods for Chinese then GNOME could have a preferred one > but allow the user to choose anything that is installed even if the user > chooses to install fifty more. You'd end up doing the exact same work, in 2 different ways. As we have limited control to those downstreams (the IBus developers might not be the same ones as the engine developers) or even to the packagers, it's quicker, and we offer better turn around (directly in touch with the users, rather than through layers), which are beneficial you can see from your own comment 3.
(In reply to comment #10) > You'd end up doing the exact same work, in 2 different ways. As we have limited > control to those downstreams (the IBus developers might not be the same ones as > the engine developers) or even to the packagers, it's quicker, and we offer > better turn around (directly in touch with the users, rather than through > layers), which are beneficial you can see from your own comment 3. As I said, I am mostly concerned about the delay introduced by handling this in GNOME. By the time GNOME decides to (un-)whitelist some software and it actually makes it into a distro release the software itself may very well change its status to either fixed or obsolete (thus needing the decision to be reverted). As you say this can be fixed by the downstream by patching the whitelist but the people who do so (packagers) are in the best position to actually only ship software that works (drop unworthy packages from distro, add worthy ones to default install etc.).
(In reply to comment #8) > (In reply to comment #7) > > Sure but would you recommend shipping the 777? It's much easier for Fedora to > > change their default install than for GNOME to track the ever-changing list of > > existing plugins. > > It's only 6 different packages, and each one of those contains useful engines. > > > I don't see how IBus engines are different from GStreamer plugins, GTK+ modules > > or Xorg drivers. > > The GStreamer plugins and Xorg drivers aren't user visible. I don't put them in > a list for the user to choose. The IBus engines are all listed when you add a > new input source. I don't think that having 200 different engines marked > "Chinese" is going to help users. But masking out useful Chinese engine (either exist or in-development) is definitely annoying! If GNOME really insist on whitelisting input method engine or any other third-party plugins, then please provide a way to make other input method engine or plugins to *get in* the whitelist as soon as possible!
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > It's only 6 different packages, and each one of those contains useful engines. > > > > Ouch. Can these be safely split to only install the really useful ones? > > > > > The IBus engines are all listed when you add a > > > new input source. I don't think that having 200 different engines marked > > > "Chinese" is going to help users. > > > > I wholeheartedly agree that having to choose from a list of hundreds of > > seemingly identical options is suboptimal but I see no reason to package the > > hundreds in the first place. If we cut the list of installed by default down to > > three or so useful methods for Chinese then GNOME could have a preferred one > > but allow the user to choose anything that is installed even if the user > > chooses to install fifty more. > > You'd end up doing the exact same work, in 2 different ways. As we have limited > control to those downstreams (the IBus developers might not be the same ones as > the engine developers) or even to the packagers, it's quicker, and we offer I don't think that's your concern. I have been the maintainer (not very actively though in the last year) of sunpinyin input method, and over the past whole year, we didn't hear from any developers from the GNOME camp who's been working on this whitelist thing. There's no email to the mailing group or personally, there is no inquiries on the stableness of our current release, there is not even a bold font announcement on GNOME Live. From our perspective, GNOME don't seems to care about working with the downstream developers *at all*. If it wasn't because of this whitelist thing, we wouldn't even know that we were banned! On the document of input source[1], there is no explicitly saying *no third party engine is allowed*. Except for this and bug 682313 report, that's all. > better turn around (directly in touch with the users, rather than through > layers), which are beneficial you can see from your own comment 3. Again, let me clarify. I'm not even against the idea "if you're not GNOME developer, your software could never be used by GNOME". But, please please please notify us (explicitly, bold font or even somebody's blog that can be reached by Google) when you decided to blacklist us. Otherwise, it's really hard to tell whether GNOME want to work with the downstream developers or not. [1] https://live.gnome.org/ThreePointFive/Features/IBus
(In reply to comment #12) > But masking out useful Chinese engine (either exist or in-development) is > definitely annoying! It's a one-liner to make them show up. > If GNOME really insist on whitelisting input method engine or any other > third-party plugins, then please provide a way to make other input method > engine or plugins to *get in* the whitelist as soon as possible! You file a bug with the engine name, and the reason why it should show up in the whitelist. It's about as easy as adding a comment to this bug!
As per comment 1.
Dear Bastien, I read about this upcoming change in GNOME 3.8 (?) and become deeply concerned. If I understand correctly, the normal end-user would have no way to edit or override the whitelist without going through some non-trivial operations, whether it be recompiling parts of GNOME from source, or changing some undocumented GConf settings. I really can't see how a non-tech person can do that. It is a big usability issue. I can already see the backlash in the Chinese community if things stay this way when GNOME 3.8 is released and reaches end-users through various distros. If you really, really have to use a whitelist, why do you: 1. hardcode the whitelist in C code and not in a text config file or in GConf? 2. not make the option of switching off the whitelist filter very user-visible in the GNOME Control Center? 3. not make the whitelist user-editable in GNOME Control Center? Or am I mistaken? Please enlighten me. :-) Many thanks!
(In reply to comment #14) > (In reply to comment #12) > > But masking out useful Chinese engine (either exist or in-development) is > > definitely annoying! > > It's a one-liner to make them show up. > > > If GNOME really insist on whitelisting input method engine or any other > > third-party plugins, then please provide a way to make other input method > > engine or plugins to *get in* the whitelist as soon as possible! > > You file a bug with the engine name, and the reason why it should show up in > the whitelist. It's about as easy as adding a comment to this bug! 0. the engine name is called sunpinyin. see https://github.com/sunpinyin/sunpinyin/blob/master/wrapper/ibus/data/sunpinyin.xml.in 1. Then what? Making every users waiting for the next GNOME release? 2. I have no idea why you need this whitelist and especially hard code in C. But if you insist do so, please update the GNOME Live document[1] say GNOME is doing whitelist on input engine. Any developer should get your approval first to develop a ibus input engine for GNOME. Blocking other people's work *without notifying* is rude. [1] https://live.gnome.org/ThreePointFive/Features/IBus
I guess why adding a whitelist is because there are too much useless input method engines (most are in ibus-m17n). If the g-c-c shows all of them, it is really bad user experience. But I think the whitelist solution is not good enough. Because it will block out some good third parties engines. In ibus setup dialog, we are using a different way to resolve the problem. We use rank of engine to decide which engine should be removed from the default list. There is rank value of every engine. The rank below zero, should be considered as useless (most engines in m17n have rank -1.). And only show them, when users really want them (by a setting). Maybe g-c-c could use similar way. And we could also sort engines of the same language by the rank. It is very user friendly. For example: Chinese people use pinyin, wubi, erbi, zhengma and etc. But pinyin and wubi have more users. So we will put pinyin and wubi at front of the list. Please check the rank of IBusEngineDesc. https://github.com/ibus/ibus/blob/master/src/ibusenginedesc.h#L91
As already stated in comment 1, the decision is taken, and the code will stay as-is in GNOME 3.6. We might revisit the decision in the future [1]. File requests for individual engines in separate bugs with a justification. [1]: but adding your 2 cents to this bug won't make it go any faster, quite the contrary.
(In reply to comment #19) > As already stated in comment 1, the decision is taken, and the code will stay > as-is in GNOME 3.6. We might revisit the decision in the future [1]. Who? When? I think I need relevant references. > > File requests for individual engines in separate bugs with a justification. What about in-development engines? do they have to recompile everything just to start development? And please update GNOME Live, I'll try to pass this message to all Chinese developer's community as well. BTW, This really make GNOME sounds like Chinese Government. (Every website have to file request with specific justification...) > > [1]: but adding your 2 cents to this bug won't make it go any faster, quite the > contrary.
(In reply to comment #20) > (In reply to comment #19) > > As already stated in comment 1, the decision is taken, and the code will stay > > as-is in GNOME 3.6. We might revisit the decision in the future [1]. > > Who? When? On desktop-devel-list, several times in the last months. > I think I need relevant references. Feel free to download the archives at https://mail.gnome.org/archives/desktop-devel-list/index.html and find and read the threads. > And please update GNOME Live Please provide a full link what you'd like to see updated.
Hi, André Klapper Can you provide full link of related thread, then?
No I cannot, as I don't have the time to re-read extremely long and unreadable threads, due to rants and missing manners (code of conduct!) of a small but vocal fraction of non-GNOME-developers that made it impossible to have a useful technical discussion. Maybe you remember. Hence: Please search yourself in the archives.
(In reply to comment #21) > (In reply to comment #20) > > (In reply to comment #19) > > > As already stated in comment 1, the decision is taken, and the code will stay > > > as-is in GNOME 3.6. We might revisit the decision in the future [1]. > > > > Who? When? > > On desktop-devel-list, several times in the last months. > > > I think I need relevant references. > > Feel free to download the archives at > https://mail.gnome.org/archives/desktop-devel-list/index.html and find and read > the threads. > > > And please update GNOME Live > > Please provide a full link what you'd like to see updated. https://live.gnome.org/ThreePointFive/Features/IBus
(In reply to comment #23) > No I cannot, as I don't have the time to re-read extremely long and unreadable > threads, due to rants and missing manners (code of conduct!) of a small but > vocal fraction of non-GNOME-developers that made it impossible to have a useful > technical discussion. Maybe you remember. > Hence: Please search yourself in the archives. I've search the titles of recent 4 months, couldn't find anything. So...Filtering of input engines happened when 1. nobody remember when and under what background 2. nobody know who suggested this idea and whether that person is qualified to investigate in qualities of ibus-engines in other language. Given that such a huge decision is heavily lack of documentation on GNOME Live, shall we now reconsider about removing this whitelist, and solve this problem in some other developer polite way?
> On desktop-devel-list, several times in the last months. > No I cannot, as I don't have the time to re-read extremely long and unreadable > threads, due to rants and missing manners (code of conduct!) of a small but > vocal fraction of non-GNOME-developers that made it impossible to have a useful > technical discussion. Maybe you remember. Don't spaming on something you don't know. Thank you very very much.
(In reply to comment #19) > As already stated in comment 1, the decision is taken, and the code will stay > as-is in GNOME 3.6. We might revisit the decision in the future [1]. > > File requests for individual engines in separate bugs with a justification. > > [1]: but adding your 2 cents to this bug won't make it go any faster, quite the > contrary. Why take the blame and extra maintenance yourself? Why wasting your valuable time on arguing with pesty end-users and doing the manual labour on examine the input methods you don't actually interested in? Let the IBus maintainers, distro distributors and package maintainers worry about what to show or not. IBus, as Peng Huang states, already has ranking system that set the threshold. distro distributors can set the policy of what to be include or be the default, and what you have to install explicitly. Package maintainers can categorize the input methods into "frequently used package" and "extra-packages". So for your own sake, please remove the white/black lists and let the input method stakeholders pull their own hairs.
(In reply to comment #27) > Why wasting your valuable time on arguing with pesty end-users and doing the > manual labour on examine the input methods you don't actually interested in? <snip> > So for your own sake, please remove the white/black lists and let the input > method stakeholders pull their own hairs. We are interested in IM, and we are stakeholders. Seeing as we did the integration work , and we would be to blame if the experience wasn't up to our expectations, it's only fair that we control that work.
(In reply to comment #28) > We are interested in IM, and we are stakeholders. Seeing as we did the > integration work , and we would be to blame if the experience wasn't up to our > expectations, it's only fair that we control that work. Thank you for showing interest and concern of input method. Having a great quality GNOME is what we all want. In terms of quality, I suppose that you have implement input method acceptance criteria. Please enlighten us.
(In reply to comment #29) > (In reply to comment #28) > > We are interested in IM, and we are stakeholders. Seeing as we did the > > integration work , and we would be to blame if the experience wasn't up to our > > expectations, it's only fair that we control that work. > > Thank you for showing interest and concern of input method. Having a great > quality GNOME is what we all want. In terms of quality, I suppose that you have > implement input method acceptance criteria. Please enlighten us. comment 14.
As ibus-table-chinese maintainer, I would like to share my experience on Chinese input methods: 1. There are hundreds of input methods, each could have dozens of variants. http://input.foruto.com/source/index.html (in Chinese) gives you an idea how long the white-list might grow. And it does not even contain Wubi Haifeng, which is in ibus-table-chines BTW, white list "wubi" probably does not work, as in ibus-table-chinese, there are WuBiHaifeng86 and WuBi-Jidian-86-JiShuag-6.0 2. You also need to check the actual license and patent status. Many "open/free" input methods are actually ripped from proprietary ones. BTW, in your case, you do need to support the proprietary ones. Otherwise, people using ZhengMa and Boshami (The most popular proprietary input method amongst Taiwanese professional typists) will be rejected by GNOME. 3. Each table contains thousands of lines, so manual inspection is not feasible. If you are willing to take on those efforts. I am more than happy to pour my list of input methods to you.
(In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #28) > > > We are interested in IM, and we are stakeholders. Seeing as we did the > > > integration work , and we would be to blame if the experience wasn't up to our > > > expectations, it's only fair that we control that work. > > > > Thank you for showing interest and concern of input method. Having a great > > quality GNOME is what we all want. In terms of quality, I suppose that you have > > implement input method acceptance criteria. Please enlighten us. > > comment 14. Does "Somebody actually use this input method." count? What else you need? :-) BTW, my dad actually use "easy", the Name in ibus-table-chinese is EasyBig. Please add it.
As someone had fun with ibus-table, ibus-table-chinese and IBus project in general. I have to reemphasize reason number 2: """ 2. ibus-table and ibus-m17n allow creation of customized engine, however, these engines won't appear in input source list, either. Example: http://code.google.com/p/ibus/issues/detail?id=1544 """ There are several issue reports in IBus tracker regarding customized table creation of ibus-table.
After talked this with my manager, and he raised a good point: Does the whitelist actually improve performance? If it does speed up the loading time significantly, it may worth the effort in maintaining the whitelist.
(In reply to comment #20) > (In reply to comment #19) > What about in-development engines? do they have to recompile everything just to > start development? Hey, I'm developing a new input method engine, so I thought I'd chime in. :) First of all, no, we don't have to recompile everything: $ gsettings set org.gnome.desktop.input-sources show-all-sources true There, my in-development engine now appears in GNOME Control Center, which allows me to test it. Second, my engine is currently under heavy development, and the UX is not yet satisfying. So not being "blessed" by the whitelist absolutely doesn't bother me. To tell you the truth, it's actually a relief: it means I won't be bothered by bug reports from users about things I already know are broken. Once I think the engine is ready for prime-time, I'll do what comment #14 suggests. Conclusion: the whitelist doesn't prevent anybody to work on a new engine, this specific argument just doesn't hold at all.