Re: atypical compose key

On 9/28/06, Andriy Gapon <avg icyb net ua> wrote:
The problem is with my unusual Compose key (Multi_Key), I defined it to
be <Ctrl>+<Menu> (because <Menu> is used already for something more
frequently needed, the same goes for LWIN/RWIN, and Ctrls/Alts/Shifts
are out of the question).
The problem is that this combination is not treated as GDK_Multi_key
should be. I looked through the code and did some debugging and it seems
that GTK does not expect that GDK_Multi_key could be generated with a
complex combination involving Ctrl or Alt.
In gtk_im_context_simple_filter_keypress() there is a check that rejects
anything that *might* turn out to be an accelerator sequence.
Code-wise it looks like:
       if (event->state &
          (gtk_accelerator_get_default_mod_mask () & ~GDK_SHIFT_MASK))
        return FALSE;
I believe that this is a check for a current key being pressed while
some modifier key is held down and I think that Ctrl and Alt are always
in the default modifier mask (Shift is explicitly ignored in this check).

Right.  One way to solve this problem is using input method framework
using key snooper (like SCIM), or using toplevel event (like uim),
which can be used with GTK_IM_MODULE=XXX (name of input method) if you
installed them.  These input method uses internal Compose sequences
instead of (before) gtkimcontextsimple.

Basically, I would like to know if it would be reasonable to augment the
above check, so that we do not reject current key if it is GDK_Multi_key
even if some modifiers are set. E.g.:
      if ((event->state &
          (gtk_accelerator_get_default_mod_mask () & ~GDK_SHIFT_MASK))
          && event->keyval != GDK_Multi_key)
        return FALSE;
I've verified - this works for me.

Obviously such a change would make me (and maybe couple of other
fellows) happy. And I don't think that it will break anything for
anybody as it seems highly unlikely that someone would define something
like <Alt>+<Compose> as a GNOME accelerator key. But of course this
might still be possible.

What do you guys think ?

I don't think this cause any problem on accelerated keys.  These event
is treated before gtkimcontextsimple AFAIF, but I may be wrong.

Etsushi Kato
ek kato gmail com

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