Trying to improve x49gp
10-09-2018, 03:13 PM
Post: #61
 3298 Member Posts: 117 Joined: Oct 2014
RE: Trying to improve x49gp
(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.

Attached File(s)
10-10-2018, 02:25 PM
Post: #62
 Claudio L. Senior Member Posts: 1,699 Joined: Dec 2013
RE: Trying to improve x49gp
(10-09-2018 03:13 PM)3298 Wrote:  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.

Done, patches 34,35 and 36, as well as removal of that old file are committed to the repo.

I also made a couple of changes to complement your own about the deleted labels that shouldn't have been deleted:
* I changed the word "MAIN" on P with "MENU", I think it's clearer.
* Added PREV.M, DEL, ABS, ARG, PRG, NUM.SLV, TIME, CONVERT, BASE, LIB, CMPLX, ARITH and ENTRY missing labels, as those keys are implemented.
* I also added CUT, COPY and PASTE, as well as BEG, END, and UPDIR to the cursors. Doesn't look too great but they are all important shortcuts to remember.

So go ahead, pull and rebuild.
10-10-2018, 09:21 PM
Post: #63
 brickviking Senior Member Posts: 334 Joined: Dec 2014
RE: Trying to improve x49gp
Perhaps the "END PASTE" could be shifted right by a pixel or three, but yes, they don't look great. At least they're there, and don't look like the 49G. Still, that's merely my opinion, to be taken with a very large container of Himalayan Pink salt. Nice work on the rework, by the way.

Would it be worthwhile adding the newrpl image to the collection, or does that change too often to be useful?

I've managed to chuck everything into the one .x49gp directory, and I select between all three by feeding x49gp with a config parameter: x49gp ~/.x49gp/config-{50,49+,newrpl} etc. It was "fun" building the individual versions though, amazingly I even found a "HP-49" for my 49+ so the BIOS version comes up "correctly" though as mentioned earlier, even this can be taken with 64.79 mg of salt.

(Post 305)

Regards, BrickViking
HP-50g |Casio fx-9750G+ |Casio fx-9750GII (SH4a)
10-10-2018, 09:50 PM
Post: #64
 3298 Member Posts: 117 Joined: Oct 2014
RE: Trying to improve x49gp
(10-10-2018 02:25 PM)Claudio L. Wrote:  Done, patches 34,35 and 36, as well as removal of that old file are committed to the repo.
Thanks! That was quick. Looks like our faithful customer brickviking is already happy.
(10-10-2018 02:25 PM)Claudio L. Wrote:  I also made a couple of changes to complement your own about the deleted labels that shouldn't have been deleted:
* I changed the word "MAIN" on P with "MENU", I think it's clearer.
* Added PREV.M, DEL, ABS, ARG, PRG, NUM.SLV, TIME, CONVERT, BASE, LIB, CMPLX, ARITH and ENTRY missing labels, as those keys are implemented.
* I also added CUT, COPY and PASTE, as well as BEG, END, and UPDIR to the cursors. Doesn't look too great but they are all important shortcuts to remember.

So go ahead, pull and rebuild.
See, that's the benefit of having the main newRPL developer in the loop - x49gp gets more up-to-date keyboard labels than newRPL's own simulator! (Just teasing you ... but the simulator should probably get those labels too, eventually. A cropped x49gp screenshot would do in a pinch.)

The cursor key labels do indeed look a bit weird due to their collision with the edges of the inset area between the cursor keys, but maybe we could move the texts around. Especially the texts above the left and right keys get uncomfortably close to the up key. They could be shoved away by adding spaces (kind of hacky, but it works) at the right end of the left key's text and at the left end of the right key's text, and perhaps a letter could be dropped... BEG and END are already as short as they can be without making them too hard to understand, COPY could maybe lose the O (pretty much everybody understands CPY), but PASTE ? Would PSTE be understandable enough? I'm not sure.
I tried changing the texts to
Code:
"BEG CPY   "
(3 spaces at the end) and
Code:
"      END PASTE"
(6 spaces at the start), and I think it looked better already. It would be even better if they could also go up a few pixels because the labels look like they are touching their keys (just one or two pixels, otherwise "UPDIR" collides with F5), but that would need a special case in the drawing code (we could check for key->shape==UI_SHAPE_BUTTON_ROUND). I haven't done that yet; I'm sure it would be simple though. By the way, the main and letter labels didn't need to be changed from NULL to "", that was only necessary for the on-key labels, not the adjacent ones. There are other places where you switched from NULL to "": on Alpha, 2, 7, and 9 the letter and the leftshift labels are affected, on 1 just the letter label. For the letter labels this doesn't do anything, for the leftshift labels this causes the rightshift label to be right-aligned above the key. That of course isn't tragic either, but combined with the single-shift-label keys that came from my patch (which get centered due to the use of NULL; currently ASIN, ACOS, ATAN, CLEAR (see below), OFF, ->NUM) this creates a slight visual inconsistency.
DEL is on the list of the labels you said were added back, but I can't find it ...? I'm assuming it should be in its old position as left-shift label of backspace, but that is still NULL.
And finally, what about the CANCEL label below ON? Should that be restored as well, or does interrupting a program work different enough on newRPL that it's better to leave it out? (You can probably tell I never got around to testing newRPL myself.)
10-11-2018, 02:43 AM
Post: #65
 Claudio L. Senior Member Posts: 1,699 Joined: Dec 2013
RE: Trying to improve x49gp
(10-10-2018 09:50 PM)3298 Wrote:  See, that's the benefit of having the main newRPL developer in the loop - x49gp gets more up-to-date keyboard labels than newRPL's own simulator! (Just teasing you ... but the simulator should probably get those labels too, eventually. A cropped x49gp screenshot would do in a pinch.)

The cursor key labels do indeed look a bit weird due to their collision with the edges of the inset area between the cursor keys, but maybe we could move the texts around. Especially the texts above the left and right keys get uncomfortably close to the up key. They could be shoved away by adding spaces (kind of hacky, but it works) at the right end of the left key's text and at the left end of the right key's text, and perhaps a letter could be dropped... BEG and END are already as short as they can be without making them too hard to understand, COPY could maybe lose the O (pretty much everybody understands CPY), but PASTE ? Would PSTE be understandable enough? I'm not sure.
I tried changing the texts to
Code:
"BEG CPY   "
(3 spaces at the end) and
Code:
"      END PASTE"
(6 spaces at the start), and I think it looked better already. It would be even better if they could also go up a few pixels because the labels look like they are touching their keys (just one or two pixels, otherwise "UPDIR" collides with F5), but that would need a special case in the drawing code (we could check for key->shape==UI_SHAPE_BUTTON_ROUND). I haven't done that yet; I'm sure it would be simple though. By the way, the main and letter labels didn't need to be changed from NULL to "", that was only necessary for the on-key labels, not the adjacent ones. There are other places where you switched from NULL to "": on Alpha, 2, 7, and 9 the letter and the leftshift labels are affected, on 1 just the letter label. For the letter labels this doesn't do anything, for the leftshift labels this causes the rightshift label to be right-aligned above the key. That of course isn't tragic either, but combined with the single-shift-label keys that came from my patch (which get centered due to the use of NULL; currently ASIN, ACOS, ATAN, CLEAR (see below), OFF, ->NUM) this creates a slight visual inconsistency.

My bad, and I did it on purpose. I understood from you previous posts that if one string was NULL the next one wasn't going to be displayed, so I changed to "" all NULLs to the left of any nonempty label.

(10-10-2018 09:50 PM)3298 Wrote:  DEL is on the list of the labels you said were added back, but I can't find it ...? I'm assuming it should be in its old position as left-shift label of backspace, but that is still NULL.
I added it, not sure where but I did... Yes it's supposed to go in the usual place
(10-10-2018 09:50 PM)3298 Wrote:  And finally, what about the CANCEL label below ON? Should that be restored as well, or does interrupting a program work different enough on newRPL that it's better to leave it out? (You can probably tell I never got around to testing newRPL myself.)

Nope, we can leave Cancel out. In newRPL you need to do On-A-C to stop a program, and it will ask for confirmation. I always got annoyed when my programs got interrupted accidentally, so I made it more involved "by design".
By the way, it's about time you try newRPL, either on-calc, on a PC with x49gp, PC with newRPL Desktop, or now on Android. I don't think you have any valid excuse not to.
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)