On Thu, Nov 22, 2012 at 4:30 PM, Bastien Nocera <[email protected]> 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? _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
