Trying to improve x49gp

[3298]

(10-05-2018 11:26 AM)3298 Wrote:  I think the best way to support a NewRPL-adapted UI in x49gp would be to add variants of the existing "hp49g+" and "hp50g" models which use the same base image and the same bootcode as the existing ones, but with modified copies of the label definitions. That would actually be pretty easy: some light modifications to the existing model checks, and altered copies of the "static const x49gp_ui_key_t x49gp_ui_keys[]" and "static const x49gp_ui_key_t x50g_ui_keys[]" arrays (the difference between these is just a little bit of color - on the 49g+, the left-shift and right-shift keys have white labels, on the 50g they are black).
With a picture of the NewRPL Simulator in front of me (haven't had a reason to install it yet), I should be able to do this in a couple of minutes.

I just did what I described in the quoted post. It seems that apart from moving STO|> and RCL from K to M, almost all modifications compared to a regular 50g are erased key labels. The remaining modifications are three additional labels above rightshift, leftshift, and alpha which explain which physical keys the simulator binds them to.
You'll see some differences between the newRPL simulator and the new keyboard layouts for x49gp. These are:
- The keybind hints above rightshift, leftshift, and alpha are not present. They don't match x49gp's keybinds anyway.
- I assumed erasing OFF was done because it doesn't make much sense in the simulator, but x49gp supports being turned off, and the firmware surely does as well, so I kept that label.
- The newRPL wiki says that the P key acts as a main menu key, so instead of erasing the SYMB label I replaced it with a MAIN label.
- x49gp's label placement code centers labels for the rightshift or leftshift planes above the key if the other one is absent. I could enforce the right/left-aligned placement by using "" as label instead of NULL (like I had to do for the main labels on G, H, I, J, K, L, because the absence of a main label apparently makes x49gp assume it's dealing with a cursor key, which causes the letter label to be omitted as well), but I don't think that's necessary.
- Because the K and M keys get different font sizes in x49gp, the STO|> label looks different. I had to condense it too, otherwise it would have collided with the M.

There was an ancient bug in x49gp's keyboard layout handling, which caused only one of the two previously existing layouts to ever be used. The differences between the two were minimal, which explains why nobody noticed it. I spotted it in the code when I wondered how to hook up the new layouts properly - the significant differences of these to the old ones would have exposed it, because the bug kind of defeats the purpose of this patch. I'm tempted to file the peculiar behavior concerning keys without a main label under the "bug" category as well, but I didn't bother fixing that because it was so easy to work around (empty label instead of no label at all).

You can get the newRPL layouts to appear by modifying the calculator type in the config file (look for a line starting with "type=" without the quotes; and make sure that x49gp is not running, otherwise exiting it will overwrite your changes). In addition to the old types "hp49g+" and "hp50g" there are "hp49g+/newrpl" and "hp50g/newrpl". Apart from the labels these types behave identically to the corresponding type without "/newrpl" suffix.

As usual, my commit message:

Code:

Add newRPL keyboard layouts via new calculator types "hp49gp/newrpl" and "hp50g/newrpl"
Also fixes an old bug causing only a single keyboard layout to be used, regardless of selected calculator type.
It appears nobody noticed this bug because the only two layouts present before this commit were almost identical.

Claudio: patches 34 and 35 didn't make it into your repository yet. While this one doesn't depend on those, the missing files incident convinced me that I need to do a better job at checking for desyncs between us. Also, you can probably delete qemu/qemu-0.9.0.tar.gz, because as of patch 26 (which removed the broken option to build with the older QEMU version) it's no longer used.