Re: 3.6 Feature: IBus/XKB integration

[Marguerite Su <i marguerite su>]

On Tue, May 15, 2012 at 12:32 AM, Sergey Udaltsov
<sergey udaltsov gmail com> wrote:
>> I do not want to see iBus integration becomes another Power Off Button on
>> GNOME Shell.
> IMHO the useful discussion should be from two directions.
>
> One direction - from the user POV. Here, the goal is to define the
> experience that would make CJK (and other) users happy. To collect the
> requirements to the "perfect IM integrated into GNOME". That task
> needs a lot of input from the people of those nations. But that
> discussion, ideally, should not mention existing IM frameworks.
> Functionality, not names. Otherwise it will be endless "IM1 is better
> than IM2 for language L1, while IM2 is better than IM1 for language
> L2" flamewar.
>

yes, no more flame war, please, everyone.

and we have debate between "perfect IM integrated into GNOME" and

"3 sides invents perfect IM protocol for GNOME. 3 sides join hands to
make both IBUS/FCITX/OTHER FUTURE IMs good with GNOME."

if only "one" IM, certianly it comes to a flame war.

IBUS developers are unhappy, or FCITX ones, or GNOME ones.

I thinks all of you are already unhappy now.


> The second direction - from the architectural POV: what would be the
> interface that could allow any "slightly less than perfect" IM (or
> multiple IMs - if it is possible) to be integrated into GNOME.
> Perhaps, that part can be discussed even by people without immediate
> IM experience - just knowing what Gtk/Gnome-control-center/... can and
> cannot do. And looking at the requirements and ideas expressed by the
> first "table".
>
> After that, there could be fair competition among IM solutions.
>

yes, competition is good. collaboration is good. standard to
freedesktop.org is good.

or a deep-GNOME-intregrated IBus will also harm IBUS too.

because it's not GBUS.

so if it goes into GNOME side. other sides will take bad results.

and that's where GNOME developers can not fix.

> Yes, there can be another approach, which I guess is the worst of all
> (but still some people like it, I know) - pick one existing IM
> framework, make it hard dependency, and start fixing its bugs, without
> giving alternatives any chance...

yes, the worst case. but it's what GNOME developers want before.

they're now facing this problem directly and wish to change, maybe a
little bit,

maybe BIG progress.

> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Marguerite