Re: [hatari-devel] Recent symbolic keyboard mapping change

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sat, 5 Oct 2024 04:18:30 -0400
schrieb Brad Smith <rainwarrior@xxxxxxxxx>:

> On Sat, Oct 5, 2024 at 2:28 AM Thomas Huth <th.huth@xxxxxxxxx> wrote:
> 
> > But you are mixing multiple topics in one big patch, and that makes it very
> > hard to discuss and apply single topics.
> >  
> 
> Okay, I should clarify, the PR is a mechanism for code review here. This is
> not something I want you to merge as is. I didn't think you even used the
> github's PR system directly, I was just doing this for illustration.

Well, that's the point, we don't use github in the Hatari project, it's
just a mirror, so please don't open PRs there (I still try to handle them
in case someone opens one, but I'm more or less the only one looking at
them, the other developers normally are not aware of patches that are
posted there, so this is bad). For reviewing patches, please send them here
to the mailing list, or stick them in a branch in your public repository
somewhere and post the URLs here to the mailing list.

> First, why did you switch back from "return 0x..." to "code = 0x..." in all
> > the new functions? Using "return" was way less source code, so I don't
> > quite see the point here?
> >  
> 
> You introduced this disparity when you had the _default map in one style
> and other maps in another style.

Yes, I know ... no clue why I used that "code = ...; break;" way ten years
ago when a simple "return" is much easier. I'm thinking of switching the
whole default function to "return" - but maybe that's something for the
SDL3 convertion when we have to touch most lines anyway.

> > Second, I'm not convinced that e.g. mapping SDLK_EXCLAIM to 0x02 is really
> > such a good idea. I thought we agreed that keeping the symbolic mapping
> > available in Hatari was good for people being able to get the same
> > character in their emulated system when they press the corresponding key on
> > their host system. Now if a user of a French keyboard presses "!" on their
> > host system (which seems to be a key in the lower right of their keyboard),
> > they end up with a "1" in their emulated system. That's certainly not what
> > they expected. Ok, if the press Shift-! they finally get the "!" on the ST
> > side, but from a host keyboard perspective, that's not a "!" anymore, but a
> > "µ". So I think that's rather confusing than helpful. So in my opinion we
> > should 1) only map keys when there is a 1:1 mapping possible (without
> > pressing shift or another modifier key) and 2) provide some mappings for
> > keys that are not reachable at all by other means (e.g. the ST's UNDO key).
> >  
> 
> I think it's important to have, but there are multiple goals with this in
> mind.
> 
> The primary problem, the worst problem a user can have in this area is
> there being an ST key that they want to press, but cannot figure out any
> way to press from their keyboard. We should minimize this problem as much
> as possible. Obviously 100% coverage is not possible for all host to TOS
> mappings, but it's definitely possible to provide this with every matched
> host vs. TOS language at least, but a small handful of cases will be
> arbitrarily decided (4 so far, by my count).

Ok, so for French TOS, why shouldn't SDLK_EXCLAIM be mapped to 0x09 ?
You've mapped it to 0x0D in your patch, but that key is already covered by
"-" ?

> As a secondary goal, I think we should make it as easy as is reasonable to
> run a TOS other than your host language and be able to use it. If there is
> a concise and easy to implement mapping that doesn't seem to be a code
> burden, I think it should exist.

Agreed, but that also does not help with "!" I think. If a user tries to
press the ST's "2" key on a non-French TOS, they certainly don't expect
to hit the "!" on their host keyboard to get this key.

Or maybe I am wrong? Nicolas, Laurent, I assume that you are using French
keyboards, maybe you could chime in?

> Lastly, I feel that for every host keyboard covered, it is best if every
> key does something. In my view, having a small number of redundant keys
> that map to the same ST key is a benefit for the user.

Ok, fair points, but then we can also continue with the current mapping for
SDLK_EXCLAIM.

For other keys, your choices also seem to be rather random and
questionable... e.g. SDLK_QUOTE is currently mapped to 0x28. That's a valid
mapping in 4 languages (US, UK, NL, PL). You changed the default mapping to
0x0C which is only valid in 3 languages (IT, CHFR, CHDE). So what's the
advantage of your change?

> Also, consider that with the default fallback, you were not excluding
> SDLK_EXCLAIM for US TOS, you were simply allowing it to have the wrong
> code. What you're really suggesting I think would instead properly map
> SDLK_EXCLAIM explicitly to ST_NO_SCANCODE instead.

I never proposed that. I just want to keep it like we had it in the past 20
years already instead of changing the mapping in a way that I cannot really
follow.

 Thomas