Re: 3.6 Feature: IBus/XKB integration



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]