Re: 3.6 Feature: IBus/XKB integration

On 11 May 2012 15:41, Vincent Untz <vuntz gnome org> wrote:
> There's been some recent discussion wrt input methods in openSUSE:

Thanks for bringing this to my attention.

> Apparently, people seem to think that ibus is not the right long term
> solution. And fcitx has been mentioned several times, then the upstream
> author wrote this:
> When reading this thread, it sounds to me that there are quite some
> users who are unhappy with ibus. So I'm wondering: have other approaches
> been considered?

I didn't consider any other option since IBus seemed to work well
enough and has active maintainers. I also didn't know about fcitx but
its developer got in touch with me today which was nice of him (added
in CC).

But let's go a bit deeper on this topic. There are a lot of IM
frameworks, it seems that everyone is starting their own and, to be
honest, I'd like this to end. It's actively harmful because it lowers
the chances of any of them actually becoming robust and polished
enough IMO. So, one thing I'd like to see here is more co-operation
between IM framework developers. People are, of course, free to do
whatever they want but that's my opinion.

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.

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


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