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

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sun, 6 Oct 2024 05:39:08 -0400
schrieb Brad Smith <rainwarrior@xxxxxxxxx>:

> On Sun, Oct 6, 2024 at 3:06 AM Thomas Huth <th.huth@xxxxxxxxx> wrote:
> 
> > 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.
> >  
> 
> Okay, I did post the URL to the mailing list, but I could put a PR on my
> own fork if that's better for you, I just assumed the public Hatari one was
> a more appropriate place to leave something for public discussion than my
> own fork.

What's wrong with pushing your commits to a branch and posting an URL to
the patches there? Discussion should take place on the mailing list here,
so we don't need a PR for this.

>  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
> > "-" ?
> >  
> 
> I did this because SDLK_UNDERSCORE is not normally present on the FR host
> layout. $0D should have a mapping to some key on a standard French
> keyboard, and unfortunately there is no direct analog. Because SDLK_EXCLAIM
> doesn't have a direct analog on the FR TOS, that was the one I selected.
> 
> This also applies to SDLK_ASTERISK and case 178, which also had no direct
> analog, and I felt could be used to cover ST keys which also did not have a
> direct analog.
> 
> Layout: http://www.kbdlayout.info/kbdfrna

Are you sure that you looked at the right, most common layout? That page
says that default layout for French is the "legacy" layout:

 http://www.kbdlayout.info/kbdfr

And that's also what I get when searching for pictures of French keyboards.
And that keyboard has both, underscore and minus keys.

Brad, I think it might be best if we leave the fine tuning of the languages
to the people who really *use* those keyboards. It's good that there is now
a way in Hatari to distinguish the different layouts on the TOS side and a
basic support for the most usual keys on the host side, but I think the
gory details of each mapping should be best done by the persons who use the
corresponding host keyboard layouts.

> > 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.
....
> Yes, some of the mappings will be weak, but I strongly feel that after
> meeting the primary matching language goal, every remaining named semantic
> should be assigned. Even if the mapping was just French Exclaim to ST 2, if
> the user doesn't know what's on the ST numerical keys but is looking for
> something that will produce !, if they press ! on their keyboard and get 2,
> that's still a small benefit in my view. Probably at that point they would
> realize they could also just press 2, but if it teaches them that, good, I
> think this is better than the key doing nothing for them.
> 
> My viewpoint remains that not being able to press the ST key that you're
> hunting for is the worst problem the user can have with the mapping, the
> problem I'm trying to minimize. Best case, they press a key and get what
> they expect. Fallback case, they're not sure what key to press, but they
> try other keys on their keyboard and find one that presses it. Worst case,
> they press all the keys on their keyboard and none of them do what they
> want. The fallback case isn't ideal, but it's far, far better than the
> worst case, and that's my goal, to prevent the worst case when the ideal
> isn't possible.

Let me repeat: If a user has a host keyboard with a "!" on it, and they
press it and end up with a "2", this is certainly never really what they
expect.

OTOH, there could e.g. also be the case where a user uses a non-French TOS
(due to whatever reason, e.g. a certain TOS version might not be available
in French), but then uses an additional PRG on the Atari side to install a
French keyboard mapping in their emulated system. Hatari can not detect
that situation. But if we map "!" to 0x09 by default, the user will get the
right key in that situation.

So no, unless a French user tells me that mapping SDLK_EXCLAIM to 0x02 is
the better choice, I'll keep the current mapping in Hatari (and the same
applies to other similar cases).

> After thinking about it I don't think it was a good approach. I think we
> should not have "default" at all, the base case should simply be US, and
> define all other languages as overrides to that. I feel this way everything
> is much easier to compare and maintain.

No, I like the idea with the default mapping. Let's keep it that way.

In the end, we will never be able to provide the perfect symbolic keyboard
mapping for all users, there are just too many different keyboards
available around the globe (not only languages, but also PC vs. Mac etc.).

If you really want to further improve the user experience here, I think the
right way forward would rather be to add a way to the GUI to be able to
easily redefine keys there, without forcing the user to deal with
keymapping files.

 Thomas