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

[Kazunobu Kuriyama]

Adrian Robert wrote:

> > Though I don't know what the final form of the modification looks like,
> > if you
> > use XLookupKeysym() as was in the previous patch you sent in the 
> > list, the
> > modification is wrong/incomplete. I'm not responsible for that, as you
> > skipped
> > giving me a reply to my comment, thus having no chance to notify you 
> > of it.
> >
> > If this is not the case, sorry for bothering you.
>
>
> I'm not 100% sure what you are referring to.  If you are talking about 
> the handling of MapingNotify events (caused by running xmodmap, etc.) 
> that you brought up earlier, I addressed that after you mentioned it 
> (keysym-keycode mapping is re-inspected on these).  I did not send a 
> second patch out for testing this, but I can revert the CVS change if 
> someone notices a problem.  If you're talking about something else, 
> could you please remind me?  (It's possible my mail server might have 
> dropped a message of yours by accident.)  Or are you talking about 
> your more philosophical objection?
>
> thanks,
> Adrian

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.

Are you sure that the assumption always holds true?  If not, please
read the below.

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.
Although Xt provides this functionality as a function, use of it
is unlikely to be our choice.

I'd like to recommend you to skim Appendix A of X Protocol specs, if
you have not done yet, so that you can predict possible consequences
of the modification which may happen on keyboards unknown to you.

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.

This could be a possible quick fix.  But I still have yet another view...
Please read below if you will.

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.

Although I got this idea when I read the patch, I didn't say that because,
before imposing something on you, I wanted to make sure what background
or idea was behind your patch, possibly greater than mine.  Unfortunately,
I hadn't got any reply from you since then, and so was it, I thought any
further comment was not required.

That's why I raised a "philosophical" issue, though I don't consider it
as such; rather, it might be considered a design model or pattern.  So,
if one needs to break it, I guess there should have been a good reason
for it to make one's life much easier later.  When reading the patch,
it seemed to me that you took a harder way for some reason unknown to me.
That was just I wanted to know when I first replied.  But now, this is
water under the bride; I won't stick to it.

Regards,
- Kazunobu Kuriyama