Re: 3.6 Feature: IBus/XKB integration

[Weng Xuetian <wengxt gmail com>]

On Tue, May 15, 2012 at 6:18 PM, Takao Fujiwara <tfujiwar redhat com> wrote:
> (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
>>
>>
>>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Hope this feature can be implemented in gtk and clutter in near future
https://bugzilla.gnome.org/show_bug.cgi?id=651244

Thus the input widget is password or not can be easily know by input method.

My implementation for im module of gtk/qt in fcitx is to send a flag and
indicate it's password, if so input method will pass by the key.