Re: Input method support in Gtk

[Weng Xuetian <wengxt gmail com>]

On Mon, May 14, 2012 at 9:05 PM, Matthias Clasen
<matthias clasen gmail com> wrote:
> On Sun, May 13, 2012 at 2:00 PM, Weng Xuetian <wengxt gmail com> wrote:
>
> Hey, first of all, thanks a lot for coming here ! We here far too
> little from input method developers.
>
>> 1.
>> So there is a fundamental problem inside Gtk, which is Gtk cannot
>> guarantee the key event always send to input method first. This is
>> what must be ensure to make input method work correctly.
>
> This is a very old controversy:
> https://bugzilla.gnome.org/show_bug.cgi?id=90082
> I think we just have to agree to disagree on this - the toolkit can
> and does reserve certain key combinations for its own needs.
> Input methods simply can't assume that they can claim any key sequence
> - they have to work within the environment that they are operating
> in...

Yes, I'd agree with there are some case that application need the key,
but if you look at the input method, it's not necessary to guarantee
application get key even first.
All traditional Input method have a state on/off, when state is on,
key might be grabbed, and when it's off, nearly all keyevent are
ignored (in spite of the trigger key for on/off).
So there will always be a way for user to let application get all key
event, just turn input method off.
If an input method cannot be turn off (which is not the case
nowadays..), input method itself should be blamed.

And when input method is on, that will means people "really want to
type something" and should not be interrupt.

Since all existing input methods are already using gtk_key_snooper,
why not let input method to process all key event?

>
> That being said, maybe there is a case where we want to pass Tab to
> input methods, if they are doing the equivalent of focus-moving keynav
> internally.
>
>> But actually this callback requires a gboolean return value. Which
>> also cause input method cannot work correctly.
>
> This is just a plain old  bug - if signal handlers don't have the
> right signature, of course things will break. Would it be nicer if the
> compiler warned you about it ? Certainly. But then, you could just use
> a language other than C...
>
Yeah, that's a problem in C, but I think there are some way to workaround this.
1. Use some macro trick. (I'm not sure whether this should be think as
a glib feature )
Define a function prototype in header with some name convention
typedef boolean (*foobar_signal_prototype)(gpointer p);

#define type_safe_signal_connect(obj, signal_name, signal_func) \
    do { \
        signal_name##_signal_prototype dummy = signal_func; \
        g_signal_connect(obj, "signal_name", G_CALLBACK(signal_func)) \
    } while (0)

2. some automatic code check on git.gnome.org.

>> 3.
>> This is a feature request, that widget should have kinds of "Hint" for
>> input. This is being used in android and qt.
>> That a input field can indicates what the content suppose to be, such
>> as password, email address, or digit. This is a useful info for input
>> method to work better.
>
> For this, please see https://bugzilla.gnome.org/show_bug.cgi?id=651244
> and comment there - I was hoping that we could finish that up for 3.6.
>
> Matthias
Quite looking forward for this feature.

By the way.. though maybe not a problem, gtk.immodules file is quite
annoying. Is there any reason for must keep a cached file?