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.
Okay, you haven't said it directly but I have to interpret this repetition as a request that you want me to close the PR on hatari/hatari. I have instead moved it to:
The reason I used a github PR is because it provides several things at a single click:
- "Conversation" tab for commentary which does not belong in either the code or commit history
- It has other less important useful features which users of github will be familiar with.
Opening it on the hatari/hatari repository also provided the CI checks there, indicating that the code builds correctly. I can't easily reproduce the CI setup for my own personal repository, so I have lost this check. I compile the code on my own system of course, but I can't check for issues on other platforms without proper continuous integration. I'll do my best without it.
Are you sure that you looked at the right, most common layout? That page
says that default layout for French is the "legacy" layout:
Okay, I should have linked the legacy one instead, but that doesn't actually change what I said about SDLK_UNDERSCORE, I'll explain below.
Yes, for each language there is a multitude of keyboards, my effort is to understand the SDL semantic symbols that can be produced by the majority of users of that language. The keyboard reference I linked was just illustrative, and I did make a mistake of not linking the most standard one in this case, but that's really not material to this issue.
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.
I absolutely wholeheartedly agree about this!!! I think you've misunderstood the argument I'm making.
1. ST $0D (-_)
2. ST $29 (`£)
3. ST $2B (#|@~)
My opinion is that these 3 should by mapped to 3 keys commonly accessible to French keyboard users. I do not care which 3 specifically should be chosen, the ones I made are just a suggestion. A French user will have a more valid opinion than mine. My goal is just to raise this as an issue.
When I said that SDLK_UNDERSCORE (which you noted is already mapped to ST $0D) is not available on the French keyboard, this was not related to my reference to the "Standard AZERTY" instead of "Legacy AZERTY". Yes these keyboards have an underscore on 8 key, but this key is SDLK_8 which obviously has to map to ST $09. There is no SDLK_UNDERSCORE on these keyboards as far as I know. This is different than saying "there is no underscore". There is an underscore, but it's not one we can use here.
My suggestion was to use:
1. SDLK_EXCLAIM (!§) to ST $0D
(-_)
2. 176 (²) to ST $29
(`£)
3. SDLK_ASTERISK (*µ) to ST $2B
(#|@~)
This suggestion is a soft one. The real issue is there are 3 ST keys which should be pressable, and they have no obvious natural mapping. Nonetheless I feel very strongly that they must be mapped! The question of which keys would be best to map them to is absolutely something I would want French users to resolve rather than myself, but so far no-one has responded to these 3 points.
Yes, I expect my knowledge of how users of each language are used to their keyboards to be incomplete, but until we have a user in each language willing to spend time looking at this, I am trying my best to replicate the situation and investigate every key I can press. I want to put all of them in the best place they can be before moving forward.
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.
Okay I think I should clarify because I think it's got off track. You said 2, not me, which I accepted and repeated as a hypothetical, but I guess you meant ST $02, which on the US layout is (1!). It is indeed a key with an exclamation on it. That's what we should really be discussing here.
For the US TOS target, I have mapped the SDLK_EXCLAIM semantic to the only key with an exclamation on it (1!) for that TOS. This also applies to DE, UK, IT, SE, FI, NO, DK, NL, and will apply to PL when it's implemented.
For CHFR/CHDE TOS instead it went to ST $1B (¨!#), again the only key with an exclamation on it.
For ES instead it goes to ST $34 (.!).
For the FR TOS, I used $0D as mentioned above, but as I've stated it's an arbitrary choice which I do think a French user should help make.
Those are the mappings I assigned for it, which is what I am trying to discuss. I feel the assignment is simple and obvious, there is an SDLK_EXCLAIM semantic, and it should got to the key with a ! on it, except in the FR TOS case where the host to target language map takes priority, and I think we should do something else with it.
Your proposal seems to be to map it to $09 always, and in this case every TOS except FR it would now go to a key that doesn't even have a ! on it. I don't think that's better.
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.
I don't understand what we are trying to accommodate here. The user wishes to use a mapping other than what their TOS provides, so they're running ST software to remap the keys? In this case, I think the correct action is for them to override the country code from the command line. I don't think this case should have anything to do with the semantic mapping system.
> 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.
Well, I'll try to reinstate a default mapping in my branch somehow, but I am unsure what principle to follow in organizing the "default" abstraction to avoid debate. The majority principle seems untenable to me. The US map principle just makes it identical to the US map. What you had in the rewrite is a mixed map that has wrong keys for every TOS because it applies to none of them completely, and I'm not sure how to rationalize what goes into such a map.
So, I can put one back in, and if you think default should have X or Y or Z in it, you can tell me or edit it yourself or whatever, the only thing I want to argue for is the actual inputs and outputs for the user, which the default map is not directly part of.
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.).
I've said over and over, this cannot be perfect, and especially cannot be perfect for cross-language mappings. I still think we can do a lot better, and I do not think we should simply give up. Every named SDLK semantic should be used according to its semantic where possible. I don't think this is impractical or unmaintainable at all. As I'm trying to demonstrate with the PR, we already can see how much code it requires.
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.
-- Brad Smith