| Re: [hatari-devel] Recent symbolic keyboard mapping change |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi Brad,
Your write up of the actual Hatari problem that users bump into, and how
it needs to be addressed was very good/clear.
On 9.9.2023 21.53, Brad Smith wrote:
....problem description removed...
What I've been working on, is providing a set of 16 symbolic maps for the
keyboards known to me ( https://tho-otto.de/keyboards/ ) and allowing
Hatari to automatically select the chosen one based on the loaded TOS, or
override if the user chooses.
There are multiple things deciding the TOS keyboard layout. TOS can be
single language / layout, or support multiple ones. In latter case,
it's determined by TOS country code, or if machine has NVRAM, then by
NVRAM keyboard layout setting.
I can add logic (function) for that, once the mappings themselves work fine.
Because the number of TOS languages is finite
and small, it's a reasonable amount of code to provide this. With SDL
providing the semantic mapping, we eliminate one side of the host vs. TOS
permutations and it's reduced to a solvable problem.
I was thinking about this because I had to work through all 16 layouts to
provide them as on-screen keyboards in my Libretro adaptation of Hatari (
https://github.com/bbbradsmith/hatariB ). It gave me an idea of the scope
of the work, and where all the exceptions lie. I think it's feasible. I've
already done a couple of layouts and they seem to be working very well. I
just need some time to finish going over all of them. It's not complicated
work, just takes time to get through all the data entry and testing.
Whatever changes you already have related to this, could you send them
as initial draft patch series?
I'd like to see how you've integrated the changes to Hatari, and how
much additional code / tables there is so far.
So, I think it's reasonable to provide a symbolic mapping that isn't bound
to only US TOS, and could accomodate the needs of most users "out of the
box". When creating a default symbolic mapping, the priority should be
mapping the most standard version of the modern layout for that
region/language with the corresponding TOS language. Semantic keys outside
that language can also be provided for convenience, and those might have
ambiguous choices, but obviously we defer to the host layout that matches
the TOS before everything else.
....
That's why I strongly feel symbolic should be kept.
For symbolic mapping to remain relevant, it needs to support mappings
for all known TOS keyboard layouts, as user could be using any of those.
If you're offering to provide code for mapping all the 16 ones listed on
Thorsten's page, that sounds excellent!
I think with the TOS issue solved it might be a better default than
scancode mapping.
That could be considered, but let's first see how well the symbolic
mappings compare to scancode mapping. :-)
The
biggest advantage is when trying to type text, word processing, text
adventures, code editing. It's especially an advantage for someone who
wants to do such things in a TOS different than their host keyboard. Even
with the current version that only targets US TOS, it has all of this
advantage for any user using a US TOS, regardless of the host language.
The biggest disadvantage of the symbolic mapping is for situations where
the program's keyboard layout is non-semantic. For example, if a game has
fixed WASD controls, we'd probably rather a scancode mapping. I think
there's a huge value in allowing the user to have both of these tools
available.
One way to help with that, could be separate keyboard shortcut for
switching between symbolic and scancode keyboard mapping, and an
indication in statusbar on which one is currently active.
Indicator could e.g. be the keyboard language when symbolic keymapping
is active, and empty when scancode mapping is used.
I do not want to see scancode mapping or customization go away, I just want
an easier setup process for the user. Just because the current symbolic
setup isn't useful to all users, doesn't mean that it's not useful to a lot
of users. Yes, it's crap for French or German or other TOS, but I think it
has great functionality for US TOS, and it shouldn't just be trashed. It's
already worth keeping for that subset of users. With more TOS targets
available we can improve the usefulness to a much wider set of users too.
Yes, I would very much like to see this.
- Eero