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

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Fri, 4 Oct 2024 13:56:46 -0400
schrieb Brad Smith <rainwarrior@xxxxxxxxx>:
....
> > Well, what I did was basically a complete rewrite of your patches. Having a
> > full switch-case statement with all keys for *each* language looked pretty
> > much too big and unmaintainable to me, it's way easier if we only encode
> > the differences to the standard mapping.  
> 
> So, yes I felt differently about what is maintainable when I wrote it, but
> that doesn't mean I am unwilling to do this as a compromise.

Well, it's me and the other Hatari developers who finally have to maintain
this code in Hatari while you might be off to the next project, so please
understand that I did not do these changes to annoy you, but to get the
code into a shape where I can say "yes, this makes sense to me, that's
maintainable for me".

For example, in the past we e.g. added the external disassembler code
without thinking of the implications first:

 https://git.tuxfamily.org/hatari/hatari.git/commit/?id=da3bcf9d1705e4531076e5c078693988a33162af

That code was using huuuuge functions, was hard to understand, and it was a
real pain to fix bugs in there. It was a real time sink for maintenance
later, so at one point in time, I removed it again from the Hatari source
tree.

> Aside from key case changes, in my version I had written it so that NVRAM
> is not allowed to affect the keyboard mapping unless the TOS was identified
> as a multi-language TOS. In your version, you did not include this in your
> revision. I did not attempt to restore this in my PR, but I do not know why
> you chose to discard it, perhaps you could comment?

Sorry, I don't quite get the problem here. I've put the NVRAM stuff into a
"if (countrycode == TOS_LANG_ALL)" statement, so where's the exact problem
here?

> The reason I had done
> this was that I didn't think it made sense to allow NVRAM settings to
> change the symbolic mapping in conflict with the one the TOS can actually
> support. To me the case where this would happen would be the Falcon user
> switching from emuTOS to an original TOS that was not the same language as
> their NVRAM setting, and I felt that in this case the user would want
> mappings that work with the TOS in this case.

Now I'm even more confused ... Falcon TOS is a multi-language TOS, so I
cannot quite follow ... ?

 Thomas