|
From: | Adrian Robert |
Subject: | Re: [Gnustep-cvs] gnustep/core/back/Source/x11 XGServerEvent.m |
Date: | Wed, 1 Sep 2004 13:37:31 -0400 |
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 dependentand are sometimes changed during runtime; I would use KeyCodes as possibleas 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 (assumingKeySym[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
[Prev in Thread] | Current Thread | [Next in Thread] |