atypical compose key

[Andriy Gapon <avg icyb net ua>]

I do not usually use the complete GNOME desktop, but I use a lot of
GTK2/GNOME2 applications. Also, I have a very customized XKB
configuration with some quite uncommon settings. Usually I do not have
any problems using my XKB setup with GTK apps and I override XKB
settings directly using xkbcomp.
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).

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 ?

-- 
Andriy Gapon