Re: 3.6 Feature: IBus/XKB integration

[Weng Xuetian <wengxt gmail com>]

On Sat, May 12, 2012 at 11:19 AM, Owen Taylor <otaylor redhat com> wrote:
> On Fri, 2012-05-11 at 21:00 +0200, Rui Tiago Cação Matos wrote:
>
>> Then, all these projects try to do things in a cross-desktop way. This
>> isn't bad per se, but it creates several practical problems for an
>> integrated and cohesive environment like GNOME:
>>
>> - UIs which look alien;
>> - conflicts with the XKB configuration that GNOME does;
>> - conflicts with global GNOME key bindings;
>> - requiring to be explicitly enabled by the user or relying to be
>> started from X session scripts according to environment variables.
>>
>> Now, I think we all agree that this is far from a good user experience.
>>
>> I'm proposing a bargain to IM framework developers here. We are doing
>> all the UI and configuration for you and committing to maintain it
>> upstream, in an integrated way for GNOME. You are free to do whatever
>> you consider fit to support other environments.
>>
>> What I need from IM frameworks is basically:
>>
>> 1. a GTK+ IM module - these aren't a problem AFAICT since there's well
>> defined interface for them;
>> 2. a DBus API that I can use to enumerate engines, get some info about
>> them, switch and configure them;
>> 3. a DBus API to be implemented on the GNOME side that the IM
>> framework can use to present candidate windows.
>
> These are a few things we need from the input method framework, but we
> also need:
>
>  4. A sensible selection of input methods where the best-of-breed
>    input methods that most users actually want to use are the
>    ones presented.
>
>  5. Configuration and feedback user interfaces that are designed in
>    conjunction with the rest of GNOME.
>
>  6. Tight integration with accessibility and on-screen input for
>    tablets.
>
> Basically, it makes no sense to say that every aspect of the user
> interface is designed in at the GNOME level and then once the user
> needs an input method we give up.
>
>> Right now IBus allows me to do all of the above so I'm sticking with
>> it for the time being. But, if IM framework developers agree on a set
>> of well defined interfaces for points 2 and 3 above I could port to
>> them.
>
> We need to get off the train of constantly replacing not just input
> methods but entire input method *frameworks* (for Fedora, we went from
> XIM to IIIMF to SCIM to IBus). Input methods and input method developers
> have to be brought into the GNOME community; the area of input methods
> should not treated as a wild-west where anything goes.
>
> I can't think of much that's less conducive to getting things right than
> a framework for dropping in different input method frameworks.
>
> - Owen
>
I don't really want to argue that why some user don't use ibus. From
my point of view, there are some place technically it can't do well
for now. People are not satisfied just because of consistent user
feeling.

As another input method framework developer, I totally agree when you
are trying to bring consistent user feeling when you are UNDER gnome,
which is also my point, that's why I also work on general input method
gnome-shell extension.

Under a distro view, people might not use gnome, might not use ibus,
they might not be you guys or ibus guys target, but they are my
targets.

Actually what I initially asked for is make dependency a little bit
flexible under runtime, not only compile time.

If gnome guys are not in favor of a more general solution, I could
also understand that. It's free of you. But different framework will
exist, not to mention fcitx, hime under desktop, but also maliit which
targets for tablet. I hope competition can have a result of what's
best under specific scenario, but not because of not invent here.