[OpenSmalltalk/opensmalltalk-vm] f8c78a: Use translateCode primarily for translating symbol...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[OpenSmalltalk/opensmalltalk-vm] f8c78a: Use translateCode primarily for translating symbol...

Eliot Miranda-3
 
  Branch: refs/heads/Nuke-MacRoman
  Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
  Commit: f8c78a3f34bf7dea293c6526ae660b98647b2a82
      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/f8c78a3f34bf7dea293c6526ae660b98647b2a82
  Author: Nicolas Cellier <[hidden email]>
  Date:   2019-12-24 (Tue, 24 Dec 2019)

  Changed paths:
    M platforms/unix/vm-display-X11/sqUnixX11.c

  Log Message:
  -----------
  Use translateCode primarily for translating symbolic X11 keysym to OSVM keycode

For this purpose, enhance `translateCode` to handle classical Tab/Esc/Return/BS/Del keys (otherwise, we get 16rFFxx keycodes)
Note: currently, we do not differentiate Return from KeyPad Enter keys...

Move `mapDelBs` hack in `translateCode`.
Note: IMO we should nuke this heresy once for all...
It only make sense if we build the VM input layer above a deficient programming layer. We shall better not do that!
The added complexity is minor, but how many such useless "features" do we carry, for what added value exactly?

Note: if `translateCode` does not handle the keysym (it `return -1`) then we try to convert the key into a character using `XLookupString`.
If it converts to one (or more) byte characters (`buf` may be encoded UTF8 for example), then simply use the `*symbolic` keysym.
Else return -1, meaning that we do not recognize the key.

I did not change that last part, one change at a time, but it might be a better idea to just pass the `*symbolic` verbatim to the image in all cases.