Re: Concerning Keyboard Status Menu

[Ma Xiaojun <damage3025 gmail com>]

On Thu, Nov 22, 2012 at 4:30 PM, Bastien Nocera <hadess hadess net> wrote:
> I've tried setting up a number of languages following the Fedora guides
> that were available. For a majority of the languages that people have
> tested and reported on, the steps are now reduced to a single one:
> select the input method in the list.

I like this aspect too, that's why I supported your integration proposal early.

> For example, all the ibus modules that exactly replicate XKB layouts,
> simply because they were not integrated before, and duplicate
> functionality.

That's unrelated to my concerns at all.

> Some of it isn't in my power, but some Fedora contributors have been
> trying to clean up the default installation from all the duplicated
> features, other unused desktop files.

I want a decent, not more, not less, default either.
But the problem I repeated several times is that its' extremely
unfriendly for 'unsupported', 'third-party' engines now. Even if you
argue that gsettings change to show them all is still acceptable (I
don't think so, there is no reason for this superfluous,
non-discoverable, rarely documented step). The newly installed engined
are handicapped by the menu filter again. As I mentioned, it's natural
that Chinese engines have several IBus.Property that are frequently
used.

Worse, your filter even hurt almost all supported Chinese engines,
ibus-pinyin, ibus-chewing and ibus-table.

So we shouldn't to hard-coded filtering at very beginning. What we
need to do is select a set of supported engines and polish their
property menu.
Whether or not other engines are going to polish themselves also
should not 'governed' by GNOME.

> I would rather the energy was spent on figuring out what languages are
> currently badly supported, and enable the ones that are sufficiently
> useful for the majority of the users of that language.

Have you really read my previous messages?
Didn't you notice that it is almost all about Chinese?

> You can still enable showing all the input methods if it's really
> required.
>
> Daiki's been doing great work on whitelisting input methods that are of
> high enough quality and usage to show by default, and we've advanced
> greatly in the support of Indian languages.
>
> Now, can you come up with languages that are not covered currently, and
> talk to us about selecting the best engine for each of those? That would
> make a positive impact to the discussion.

That's indeed proprietary.
If a new engine appear or an old engine revive, why should its
developer ask you for whitelisting? What's good about that?
IBus is an open platform rather than a proprietary platform.
Many closed-source platform are more open than that of your current
state. They don't a white list at all.

> You seem to be thinking that we don't care about certain users, quite
> the contrary, we wanted to solve the problems where all the different
> groups of Linux users that required input methods had to come up with
> their own hacks.
Integration itself is a nice idea, but do not being proprietary, please.
Users can install a engine by installing a ibus-* package than done, now what?