Re: [Gnustep-cvs] gnustep/core/back/Source/x11 XGServerEvent.m

[Kazunobu Kuriyama]

Adrian Robert wrote:

> > The previous patch calls XLookupKeysym() with setting the second
> > argument to zero.  Furthermore, at other different places of the
> > patch, when it retrieves a KeyCode value from a KeySym vector by
> > some means, it always (possibly wrongly) assumes that only the first
> > element of the vector yields the corresponding KeyCode value.
>
> ...
>
> > When using KeySym, you have to figure out which element of the KeySym
> > vector corresponds to the key actually pressed.  You can construct
> > a logic for that by following the section 12.7 of the Xlib manual.
>
>
> As far as I understood this, the 0 element should have the 
> modifier-less keycode (no 'shift', etc.) in all cases.

As you know, X11 can assign the role of a modifier to any key; therefore,
"modifier-less keycode" doesn't make sense.  I think this is nasty, but
it's a reality.  That's why I recommended use of KeyCodes, so that one
can keep away from this nasty trap as possible.  In fact, an XKeyEvent
contains 'state' and 'keycode' fields, but not 'keysym'.  Why?  If there
were only a signle keyboard layout, say us104, the notion of KeyCode
would be redundant (or rather ridiculous).  The C structure is defined
as such so that no programmer will be annoyed with the diversity of
keyboard layouts on the earth.

>   For simply detecting ctrl/alt/cmd status the modifier state 
> shouldn't matter, since the other code in XGServerEvent is set up to 
> detect this modifier state independently, therefore correctly 
> determining, for example, whether Ctrl-Q or Ctrl-q is pressed.  Is my 
> assumption false?

Although I believe your assumption holds true on your system, I
don't think it is identically true.  For instance, almost keys
of my keyboard have four different symbols on the top of each of
them, which means one KeyCode possibly implies four different
KeySyms. In particular, on some keys, usually used as modifiers,
I can see two different symbols on each of them, one of which is
used to make easier typing a character of a local language.  The
lesson is, neither you nor I know all about keyboard layouts.

>   The doc, at least in my edition of the Xlib manual, is a bit sparse, 
> so testing seems to be the best solution (or maybe looking at the Xlib 
> source; I have no desire to do this ;).

From my view, that's because the implementation puts a over-the-top
emphasis on KeySyms.  You cannot complete a test of the patch until
it is tested with every existing keyboard layouts.  It looks as if
you abandoned a mandatory intellectual work on your side and left
it to others' hassle.  The over-simplified assumption and the
full outsourcing of the test are both problematic.

> This aspect seem to be working on my system, but as you say, there may 
> be variation on other keyboards.
>
>
> > If I were you, I wouldn't use global KeySyms, as they are h/w dependent
> > and are sometimes changed during runtime; I would use KeyCodes as 
> > possible
> > as I can, and put off the conversion of KeyCodes into KeySyms untill I
> > desperately need to do it.  By this strategy, you don't need to convert
> > KeySym values to KeyCode values to and fro in various places (assuming
> > KeySym[0]<-> KeyCode).  If this was done, it might have lead to a 
> > neater,
> > simpler implementation.
>
>
> My question with this is, how does the user specify the defaults for 
> GSFirstControlKey, etc..?  Either they must specify KeyCode directly 
> (ugly, unintuitive, and the defaults should then provide a way of 
> specifying more than two if desired), or they specify a KeySym-like 
> string, which I have been arguing should be mapped to an X KeySym to 
> provide the best tradeoff between specification and platform consistency. 

I never meant that the user should specify a user default value via
a cryptic code.  I think your idea, allowing the user to specify a
default value by a literal string, is good.  But connecting it directly
to a KeySym is a different matter.  I'm wondering why some people are
strongly tempted to identify a key with a symbol on the top of it, or
a KeySym. As xmodmap shows, such an identification doesn't make sense
at all...

That said, I think some users may find useful the functionality the
patch is to offer. On the other hand, as mentioned above, I still feel
dubious about the way of the implementation.  So, to resolve this, how
about making a compilation or runtime switch which allows the user to
select the old behavior or the new one?  This could be benefitial
to both those who want to use the functionality and those who has
somewhat idiosyncratic keyboards.  I have no preference on the kind
of switch; a runtime one would be appreciated by the user who wants
to use the functionality after making sure it works on her/his system.

- Kazunobu Kuriyama