atypical compose key

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
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

On 9/28/06, Andriy Gapon <avgicyb.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.

Cheer,
-- 
Etsushi Kato
ek.katogmail.com
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

on 28/09/2006 17:34 Etsushi Kato said the following:
> On 9/28/06, Andriy Gapon <avgicyb.net.ua> wrote:
[snip]
>> 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.

Etsushi,
thank you for the reply.
I've actually tried to play with IMs but without much luck.
I think I
understand the concept behind IMs/XIM, but practical usage
is hard to
get. Also, I don't need to input any CJK stuff and I only
use cyrillic
and extended latin input (Eastern, Central and Western
European
languages), so using some powerful IM seems like an overkill
to me.
Besides, currently I can input everything I want by running
Vim in xterm
— standard modern xfree86/x.org facilities and UTF-8 locale
are
sufficient for me.
Thus, the following question: is there any way to tell/trick
GTK
application to not use all the wonderful input processing it
has, nor
any sophisticated external IM, and simply (and fully) obey
X, just the
same way xterm does ? [This also includes using X Compose
sequences
instead of those hardcoded into GTK, etc]

[snip]
>> 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.

-- 
Andriy Gapon
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Hi,

On 9/29/06, Andriy Gapon <avgicyb.net.ua> wrote:
> on 28/09/2006 17:34 Etsushi Kato said the following:
> > On 9/28/06, Andriy Gapon <avgicyb.net.ua> wrote:
> [snip]
> >> 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.
>
> Etsushi,
> thank you for the reply.
> I've actually tried to play with IMs but without much
luck. I think I
> understand the concept behind IMs/XIM, but practical
usage is hard to
> get. Also, I don't need to input any CJK stuff and I
only use cyrillic
> and extended latin input (Eastern, Central and Western
European
> languages), so using some powerful IM seems like an
overkill to me.

I can understand the situation.  But modern IMs like SCIM
[1] and/or
uim [2] have removed internal relation with CJK language,
and it uses
modular mechanism.  For example if you install uim-1.2.1,
you don't
need to load any CJK input method by default, and the
default (direct)
IM uses Compose input as in X11 as in GTK+ and Qt
environment too
(with GTK_IM_MODULE=gtk and QT_IMMODULE=uim).  It doesn't
consume any
memory related CJK input method if your don't use them.

> Besides, currently I can input everything I want by
running Vim in xterm
> — standard modern xfree86/x.org facilities and UTF-8
locale are
> sufficient for me.

I also think it should be reorganize Compose mechanism in
GTK+,
especially in X11 environment, as in x.org one.  I got
reports related
to this from European people many times.

> Thus, the following question: is there any way to
tell/trick GTK
> application to not use all the wonderful input
processing it has, nor
> any sophisticated external IM, and simply (and fully)
obey X, just the
> same way xterm does ? [This also includes using X
Compose sequences
> instead of those hardcoded into GTK, etc]

uim-1.2.1 uses just the same way in x.org's Compose
mechanism in the
backend input mechanism.  So you can try to install uim
1.2.1 and use
GTK_IM_MODULE=uim as a environmental variable for GTK apps. 
This
doen't load any CJK related input method, and all the
Compose
sequences in x.org is available.

[1] http://uim.freedesktop.or
g/
[2] http://www.scim-im.org/

Cheers,
-- 
Etsushi Kato
ek.katogmail.com
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

On 9/29/06, Etsushi Kato <ek.katogmail.com> wrote:
> > Thus, the following question: is there any way to
tell/trick GTK
> > application to not use all the wonderful input
processing it has, nor
> > any sophisticated external IM, and simply (and
fully) obey X, just the
> > same way xterm does ? [This also includes using X
Compose sequences
> > instead of those hardcoded into GTK, etc]

I forgot to mention that using XIM (without any XIM server,
i.e.
setting XMODIFIER=im=none) may work for your situation
(GTK_IM_MODULE=xim).

Cheers,
-- 
Etsushi Kato
ek.katogmail.com
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

on 28/09/2006 19:00 Etsushi Kato said the following:
> On 9/29/06, Etsushi Kato <ek.katogmail.com> wrote:
>>> Thus, the following question: is there any way
to tell/trick GTK
>>> application to not use all the wonderful input
processing it has, nor
>>> any sophisticated external IM, and simply (and
fully) obey X, just the
>>> same way xterm does ? [This also includes using
X Compose sequences
>>> instead of those hardcoded into GTK, etc]
> 
> I forgot to mention that using XIM (without any XIM
server, i.e.
> setting XMODIFIER=im=none) may work for your situation
> (GTK_IM_MODULE=xim).

I've actually googled up this advice but it did not work for
me: when I
type <Compose><C><=> I get "="
instead of expected EuroSign and also
when I switch (through XKB) to Ukrainian or Russian keyboard
layout and
type some text I get some funny pairs of characters,
something vaguely
looking like what I was getting when I viewed Unicode/UTF-8
text as a
single byte text.

BTW, my environment:
XFree86 4.4.0
FreeBSD 6.1
uk_UA.UTF-8 locale
GTK 2.8.20

-- 
Andriy Gapon
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

on 28/09/2006 19:15 Andriy Gapon said the following:
> on 28/09/2006 19:00 Etsushi Kato said the following:
>> I forgot to mention that using XIM (without any XIM
server, i.e.
>> setting XMODIFIER=im=none) may work for your
situation
>> (GTK_IM_MODULE=xim).
> 
> I've actually googled up this advice but it did not
work for me: when I
> type <Compose><C><=> I get
"=" instead of expected EuroSign and also
> when I switch (through XKB) to Ukrainian or Russian
keyboard layout and
> type some text I get some funny pairs of characters,
something vaguely
> looking like what I was getting when I viewed
Unicode/UTF-8 text as a
> single byte text.

[this message is intentionally in UTF-8]

Hmm. I actually have to correct myself on XMODIFIER=im=none
and
GTK_IM_MODULE=xim — it works! but not entirely :-(
I was getting "=" instead of euro sign because of
some problem with
~/.XCompose, once I moved it out of the way compose sequence
started to
work as expected, but there seems to be some problem with
encoding. Not
sure if that problem is somewhere in X or GTK, but I suspect
the latter.

When I start gedit like follows:
env GTK_IM_MODULE=xim gedit
[XMODIFIER/XMODIFIERS setting does not make any difference]

and type my favorite <Compose><C><=> I get
the following 3-symbol garbage:
Б┌╛
[U+0411 CYRILLIC CAPITAL LETTER BE][U+250C BOX DRAWINGS
LIGHT DOWN AND
RIGHT][U+255B BOX DRAWINGS UP SINGLE AND LEFT DOUBLE]

instead of expected € [U+20AC EURO SIGN].

Again, I am doing this in UTF-8 locale (I tried my native
uk_UA.UTF-8
and en_US.UTF-8). Looks like some double-recoding ?


-- 
Andriy Gapon
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

On 9/29/06, Andriy Gapon <avgicyb.net.ua> wrote:
> on 28/09/2006 19:15 Andriy Gapon said the following:
> > on 28/09/2006 19:00 Etsushi Kato said the
following:
> >> I forgot to mention that using XIM (without
any XIM server, i.e.
> >> setting XMODIFIER=im=none) may work for your
situation
> >> (GTK_IM_MODULE=xim).
> >
> > I've actually googled up this advice but it did
not work for me: when I
> > type <Compose><C><=> I get
"=" instead of expected EuroSign and also
> > when I switch (through XKB) to Ukrainian or
Russian keyboard layout and
> > type some text I get some funny pairs of
characters, something vaguely
> > looking like what I was getting when I viewed
Unicode/UTF-8 text as a
> > single byte text.
>
> [this message is intentionally in UTF-8]
>
> Hmm. I actually have to correct myself on
XMODIFIER=im=none and
> GTK_IM_MODULE=xim — it works!

Fine 

> but not entirely :-(

Hmm...

> I was getting "=" instead of euro sign
because of some problem with
> ~/.XCompose, once I moved it out of the way compose
sequence started to
> work as expected, but there seems to be some problem
with encoding. Not
> sure if that problem is somewhere in X or GTK, but I
suspect the latter.

What is the enconding of your ~/.XCompose?  It should be
UTF-8 if it
is used in uk_UA.UTF-8 environment.  If its encoding is
uk_UA.KOI8-U,
you can get funny characters.

> When I start gedit like follows:
> env GTK_IM_MODULE=xim gedit
> [XMODIFIER/XMODIFIERS setting does not make any
difference]
>
> and type my favorite <Compose><C><=>
I get the following 3-symbol garbage:
> Б┌╛
> [U+0411 CYRILLIC CAPITAL LETTER BE][U+250C BOX DRAWINGS
LIGHT DOWN AND
> RIGHT][U+255B BOX DRAWINGS UP SINGLE AND LEFT DOUBLE]
>
> instead of expected € [U+20AC EURO SIGN].
>
> Again, I am doing this in UTF-8 locale (I tried my
native uk_UA.UTF-8
> and en_US.UTF-8). Looks like some double-recoding ?

-- 
Etsushi Kato
ek.katogmail.com
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

on 28/09/2006 20:16 Etsushi Kato said the following:
> What is the enconding of your ~/.XCompose?  It should
be UTF-8 if it
> is used in uk_UA.UTF-8 environment.  If its encoding is
uk_UA.KOI8-U,
> you can get funny characters.

Etsushi,

thank you very much and sorry for practically having wasted
your time.
It was all my fault. ~/.XCompose was not the culprit and I
removed it
anyway, but I'll try to find out exactly was wrong with it.

My main mistake was that I still somehow had CHARSET
environment
variable set and it was set to KOI8-U!
Because of this variable
  g_get_charset (&charset);
  result->mb_charset = g_strdup (charset);
g_get_charset() returned "KOI8-U" here (as I found
out with debugger)
and because of that UTF-8 result returned by
XmbLookupString() was
re-coded KOI8-U => UTF-8 which resulted in that garbage.

When I removed CHARSET and used GTK_IM_MODULE=xim everything
become perfect!

However I put a small portion of blame on GTK
[g_get_charset()] too —
why oh why did it chose CHARSET over LANG and LC_ALL ? I
always thought
that LC_ALL was an "almighty" variable.

Thank you again for your help and guidance.

-- 
Andriy Gapon
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list