Re: 3.6 Feature: IBus/XKB integration

[Takao Fujiwara <tfujiwar redhat com>]

(05/15/12 15:37), Marguerite Su-san wrote:
> On Tue, May 15, 2012 at 11:38 AM, Takao Fujiwara<tfujiwar redhat com>  wrote:
> > (05/14/12 21:34), Christophe Fergeau-san wrote:
> > > This leads to my next question, this thread so far has been focused on
> > > CJK (and Vietnamese in this email). Are they the only languages that
> > > needs input methods? Or are they needed too for arabic, hebrew,
> > > thailandese, ... ? If yes, is fcitx the IM framework to use for these
> > > too?
> >
> >
> > I think all IM framework should support the available languages.
> > Maybe I need to check some status but I don't see any critical problems.
>
> yes. both IMs now supports.
>
> > > Having an IM abstraction framework has been one recommended by some
> > > people in this thread. One concern I have with that is that the
> > > fragmentation we have now will stay, and we'll have the foo IM
> > > framework which will be favoured by people who want to input language
> > > A, the bar IM framework will be the best for language B. In such a
> > > situation, people who want to input both A and B (think A speaker
> > > learning the B language) will not get a satisfying user experience.
> > >
> > > Finally, please correct me if I misunderstood, but after reading the
> > > thread, I'm under the impression that ibus and fcitx work equally well
> > > to input CJK "characters" (except for a few ibus bugs that I guess
> > > could be fixed?). What makes fcitx better is that it provides advanced
> > > functionalities such as word autocompletion (+ highly customizable
> > > autocompletion window and online autocompletion lists), "macros"
> > > (short key sequences that will get replaced by a full word), ... My
> > > feeling about these advanced functionalities is that they are not
> > > really CJK-specific, and that this could be useful too when typing
> > > English or French texts, in which case this may be worth integrating
> > > at a higher level instead of having this in the input method? I guess
> > > the answer is that they are different things, but asking does not hurt
> > > ;)
> >
> >
> > The implementation design would be more important for me.
> > Actually I didn't think the autocompletion is so important but it would be
> > an each IM engine's issue while ibus-european-table provide that feature.
> > Probably I don't think focusing each IM engine would be good to pick up the
> > default IM framework since it would be engines' issues.
>
> see, that's the design conflicts.
>
> autocompletion directly matters to user on issue if they can input really fast.
>
> so it should be a framework's work instead of engines.
>
> if framework's good at it, every engine can benefit. like if GTK's
> good at drawing windows fast, every gtk application will benefit.
>
> yes, focusing on engines won't help, because we're discussing "IMF".

Probably I'd like to disable the autocompletion when Japanese input method is enabled so I'm thinking it's better to handle it by each engine or out 
of ibus likes GtkEntry.

BTW, auto-completion could unveil the passwords:
https://bugzilla.redhat.com/show_bug.cgi?id=803646

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