Re: Again: please clarify the decision on IBus integration


I'm glad to see you are participating public discussion on this issue.

On Mon, Jul 9, 2012 at 10:02 PM, Rui Tiago Cação Matos
<tiagomatos gmail com> wrote:
> On 9 July 2012 15:41, Aron Xu <aronxu gnome org> wrote:
>> In Rui's patches, he defines some shortcuts for switching between XKB
>> and IBus. This looks elegant, but it's problematic because IBus have
>> already defined all kinds of shortcuts, as well as users may change
>> many of them to fit their preference. The actual effect here is that
>> IBus can hardly catch shortcuts and cannot be reactivated when the
>> user switched to XKB, which is painful.
> It's true that IBus ships its own UI and keeps its own settings
> including keyboard shortcuts. But, one of the goals for this
> integration is to define GNOME settings and shortcuts for what makes
> sense to be in GNOME and expose them in GNOME UI like System Settings
> and gnome-shell. One of those is the shortcut to switch among
> configured "input sources" which allows you to switch between say a
> plain German XKB layout and Chinese (Pinyin).

I know your wish is good, so I said it looks elegant. But in real
world it's not that easy to add another layer of abstraction as "input
sources" here. First of all, IMF is actually almost what you think as
"input sources", and XKB may be a part of it. In this way users can
switch between German XKB and Chinese (Pinyin) without problem because
they are all under the management of the IMF. Such kind of work has
been their for long in IBus, as you may know ibus-xkb. The
functionality is still limited because we CJK developers don't use it
everyday like you do, but I am sure that if you are willing to adapt
to this solution then things will improve very quickly.

Adding another layer of abstraction is making the input module on
Linux much more complex, and most importantly make users more likely
to be confused. I agree that exposing IBus's settings in a consistent
way like other applications in GNOME may improve user experience if
we've done it wise, but please don't go further before you actually
get used to what's IMF and how users make use of it day by day, it's
just too risky and both you and design people need to talk more to CJK
users and developers. I guess you've learned that input method is
really something different from the long but not productive discussion
before, even if you might still don't understand it well till now.

>> Finally, because the patches is still sitting in wip branch, I don't
>> think it's approperiate to report bugs to the application itself.
> This should change soon and I'd be really thankful if you gave it a
> try then and give us feedback on it.
> Rui

I will try my best to avoid current code to be merged, and please
don't do it if you really don't want to see so much CJK users being
disappointed by a decision that you have made in house with a few guys
don't actually know what is it.

Aron Xu

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