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

[Adrian Robert]

> 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.  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?  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 ;).  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.


> Also, I'd be happy if you or someone else could update
> gui/Documentation/GuiUser/KeyboardSetup.gsdoc; so that
> the ordinary user can know how this particular modification
> is relevant to her/him; in particular, how GSFirstControlKey
> and friends are affected by the modification.

Thanks for pointing that out; I'll do it.  Not sure why this doc ends 
up in the "GUI" when it's a "Back" issue (and the GSFirstControlKey, 
etc. defaults themselves are documented there), but anyway...


Adrian