Please can you beta-test this unusual Free42 skin

[MickM]

The beta-testing has finished! Thanks to all who helped :-). Thomas has officially released Free42 v3.1 and made this skin available at:
https://thomasokken.com/free42/skins/
Note that the name changed slightly to Mueck_MN (for Metric Notation). I have removed all the beta attachments at the end of this post except the graphical documentation so you can see where everything ended up.

2023.1219: Added a new version without the metric notation row that necessitated a relayout so they could be as similar as possible.
2023.1112: Swapped 2 keys so x! could go into the statistics cluster. Updating documentation.
2023.1111: All hot-keys for Mac, Windows & Linux now work. Many thanks to Thomas for fixing bugs and improving hot-key functionality! Don't forget to download the latest test build (dated today). Rearranged some buttons and changed fonts for mathematical functions. With all bugs fixed, this is now an official release candidate.
2023.1104: Many desktop hot-key corrections for Windows & Linux, couple minor tweaks to the skin graphics.
2023.1028: Relayout for the EXIT key to the top right and several desktop app hot-key corrections (most notably for the shifted metric notation keys).
2023.1025: Initial version


For the last 3 months I've been working hard on a new skin for Free42 (which also works with Plus42 if you want the bigger screen). As you'll see below, the skin is quite complex so the chances of bugs are much higher than usual. Skins usually aren't updated on Thomas's website, and people typically don't go looking for skin updates even if they do exist, hence my request/plea for a broader audience to shake it down before release.

My motivations for making this skin included:
- My field of electronics engineering (and many other fields too) ubiquitously uses metric notation (e.g. 1.2GΩ, 3.4nH, 5.6µs, 7.8pF, 9.0 TB) so I wanted a faster way to input such numbers.
- I thought the original calculator keyboard layout wasn't great. So sick of pressing shift at the bottom and then going to the top for the most common functions, or pressing STO/RCL at the top and then going to the bottom for a number etc.
- I never liked losing the functionality of the top row of buttons if screen menu buttons were showing.
- I never liked the screen menu buttons not being aligned with the top row buttons.
- I'm constantly using physical constants and properties, but the 42S only offers π (and I detested it being a shifted key).
- I found many of the skins too hard to read (OK, so I'm old).
- I found some the desktop versions too small, the hot-keys too confusing and saw many other opportunities to improve it.
- There were several basic functions I frequently used that I wanted to add to the keyboard vs the CUSTOM menu.
- I felt the % button was too trivial ("2 7 ⇧ %" → ". 2 7 x") and warranted replacement with something else.
- I was sick of accidentally pressing the decimal point as I swiped up from the bottom to switch apps in iOS.

The documentation is in a graphics format (Mueck_MN_Doc.jpg) - it covers the skin's button layout and desktop version hot-keys (including bonus functions not available on the phone version). This is also the first skin requiring a compulsory program - CONST, a user-customizable program for physical constants and properties. Both the desktop skin and the CONST program use capabilities only available in the current version of Free42/Plus42. I'm interested in your thoughts on the default constants available in the CONST program (provided in both text and raw formats). The 1st menu level shows 6 basic constants you'd use in high school, the next level up caters more for electronics engineering, and the final 3rd level is just crazy specific - mostly to indicate that it's obvious you'd want to be tailoring it for your own needs at that point. I haven't included documentation on how to extend CONST for more or less menu levels, although comments in the text version make that pretty clear.

Regarding the skin's layout, I really sweated all the details for button arrangements, animations & spacings, and also fonts, colors, screen menu alignments... I'd appreciate feedback on the visuals and usability etc. A lot of work also went into the desktop version's hot-keys. Between the main keyboard and numeric pad layouts for macOS, Windows and Linux there are over a thousand hot-key definitions in the layout file! If your keyboard does have a numeric pad then that's the very best place to perform your basic calculations using hot-keys.

All current desktop skins try to maintain a correspondence between the keyboard keys and the calculator buttons. For example, if you've selected "1" on the keyboard as the hotkey for the calculator's "1" button then ⇧1 on the keyboard (i.e. "!") should yield "ASSIGN" just like ⇧1 on the calculator does. That's all good in theory, however all existing skins have annoying issues that create several exceptions to that key/button correspondence. For example, the calculator has a multiply button (with symbol 'x') and a shifted function above it, but the "standard" hot-key for multiply is * however you can't do ⇧* on a keyboard because it's already a shifted character (i.e. ⇧8) so you need to make hot-key exceptions for both the calculator's ⇧8 and ⇧x. Same thing goes for the calculator's add button (+). Additionally, awkward keyboard assignments arise because many calculator function names share the same first letter. In the end there are way too many complications and remembering everything is (in my opinion) just too hard. My goal was a FULLY consistent hot-key set i.e. if a hot-key was chosen for a Standard Key Mapping (shown on the skin) then the shifted version of that hot-key will always match the corresponding shifted version of the calculator button. That goal was achieved by implementing a modifier key rule for mathematical functions and two unconventional key mappings (multiply→x and add→a) for which you may have a bad first impression, but they make everything consistent with the physical calculator (and you get used to them soon enough). Note that if your keyboard has a numeric pad then those mappings can be nicely avoided because ONLY there can you physically do * & ⇧* and + & ⇧+.

When using this Free42 skin in Plus42 (for the larger display) you'll notice an unnecessary default header line at the top of the display. You can turn it off by via DISP and navigating till you find HDR. I also usually have 6 rows showing (also within the DISP menus via ROW+ and ROW-) for both the phone and desktop apps. You can also turn on the display of LASTx via DISP and navigating to LTOP. Given that Plus42's DESKTOP version is free you'll definitely want that instead of Free42's - it'll also make you want to buy the phone version of Plus42 right away like I did ;-).

So that's about it. Even if you don't want to do any testing I'd really appreciate you just looking over the jpeg file and letting me know your thoughts. Happy testing :-).
       

[dm319]

Very nice skin - I like the graphics. I also like the layout - having shift near clear is convenient for me. I'm not too sure about the placement of the EXIT key.

shift 'm' (for 'k') seems to bring up the 'modes' menu for me though.

[Johnh]

I had a look at the images and I think the rendering of labels, buttons, subtle 3d shading and soft highlights on the buttons looks really great. I haven't been successful yet in loading it onto my Android version of Free42, most probably due to my lack of understanding, though I've managed to change the skin to some others available in Free42.

I think with skins that move buttons around, its difficult to assess initially because the new layout, although it might be better, will need time to develop new familiarity. Also, if an emulator is being used in conjunction with a physical version of the calculator, then no matter what layout is used, they both need to be the same!

[MickM]

(10-26-2023 10:25 PM)dm319 Wrote:  Very nice skin - I like the graphics. I also like the layout - having shift near clear is convenient for me. I'm not too sure about the placement of the EXIT key.

shift 'm' (for 'k') seems to bring up the 'modes' menu for me though.

Thanks for your thoughts and reporting that issue.

Regarding placing EXIT beside ENTER, I honestly just did that because I thought it was cute i.e. "Enter/Exit". I'm open to change that. How about the exchanging the locations of ∑+ and EXIT? Or moving ∑+ to where EXIT is, shifting the trig functions to the left and placing EXIT above the Shift key (I'd need to think about the separating of % and %CH though)? Or feel free to propose something else.

Regarding the issue with ⇧m, I'm guessing you're on Windows (which I can't test). If I got that wrong then I've likely made many more such errors :-(. I wonder if you also have the same issue with separate pressings of shift followed by "m" (i.e. the CShift line) - could you please confirm.
Would you mind please trying something. In the layout file go to line 723 to find:
WinKey: CShift 77 : 28 117 # ⇧,m → M (Mega)
WinKey: Shift 77 : 117 # ⇧m → M (Mega)
Edit the second line to remove the word Shift, save the file and reload the skin to see if it's fixed.

Also somewhat related to the above, a virgin skin without any hot-key definitions has a full suite of default hot-key definitions, and they're kind of universally used because nobody else was dumb enough to monkey with them. I completely changed everything by making my own hot-keys. Annoyingly (well, I thought so) any default hot-key that hasn't been redefined remains in force. I brought this to Thomas's attention by saying that the remaining default keys were "polluting" my environment and I was looking for a way to wipe the slate clean before defining all of my hot-keys. However, Thomas saw the existing behavior as a feature, not a bug. Oh well.

(10-26-2023 10:26 PM)Johnh Wrote:  I had a look at the images and I think the rendering of labels, buttons, subtle 3d shading and soft highlights on the buttons looks really great. I haven't been successful yet in loading it onto my Android version of Free42, most probably due to my lack of understanding, though I've managed to change the skin to some others available in Free42.

I think with skins that move buttons around, its difficult to assess initially because the new layout, although it might be better, will need time to develop new familiarity. Also, if an emulator is being used in conjunction with a physical version of the calculator, then no matter what layout is used, they both need to be the same!

Appreciate the compliments :-). A friend had some Android issues and he responded with the following (which may or may not be useful):

On Android, use Main Menu -> Select Skin -> Load to load skins from this web site. Or, alternatively, on Android 10 or earlier, put the skins wherever you like; remember the location, and, in Free42, choose Main Menu -> Skin:
Other, and use the file selection dialog to locate and select the desired skin's layout file. On Android 11 or later, this procedure only works with skins stored in /sdcard/Android/data/com.thomasokken.free42/files.

Absolutely agree with your comment about a button rearrangement being off the table if you're also using a physical HP42S. I only use the phone and desktop versions these days - my physical calculator has the issue where the zebra connector under the LCD has dried up and half the buttons don't work as a result. Aside from that, my iPhone mini is smaller than the HP42S so that's even better. I've gotten 100% used to all the new button locations and looking at the real calculator now just makes me cringe :-).

[MickM]

One of the things I struggled with in putting EXIT beside ENTER was having LOG & LN beside them. Keystroke efficiency dictated I put the y^x, 1/x, √x row as close as possible to the numbers because they are the most frequently used functions. Next comes LOG, LN and then the trig functions (in my experience). Moving EXIT (which I think I really want to do now) has brought me to the attached graphic. Your immediate reaction will be to gag at CLEAR being decoupled from the backspace key - but think about the ergonomics. When you go shift-backspace in the current layout you next have travel to tap on the screen so that's bad from an efficiency standpoint. Given that you'll quickly get used to the new location of the CLEAR, you'll instantly see the benefit of the ergonomics of doing e.g. a CLX - it'll be as fast as possible! That also led to the realization that (ideally) you want as many shifted functions that invoke menus to be right there on the top row. That rationale made me swap PRGM and PGM.FCN. It also keeps % and %CH beside each other. I really like this much better! Thoughts...
   

[dm319]

A quick video of what I meant, running on Plus42Dec running on linux. Using the keyboard worked fine (i.e. shift-m for 'M' pressed on the keyboard did what I expected it to do).
https://youtube.com/shorts/wYzKMvhkiho

[MickM]

Thanks dm319 - that for the clarifying video. It is indeed a bug and I'll get it fixed. I'm also going to do that re-layout in my earlier post - it's just so much better!

[dm319]

That is a very nice layout. I like a lot of aspects of it. Having x<>y and R-down on the side there, as they are used regularly, having up and down near the actual menu makes sense, as you're likely to be using the menu soon after. I also agree that y^x, 1/x etc are more used than ln/log, and more so than trig. Yes, helpful to have exit somewhere in a corner - I think most people think of going to the corner to get out something, so it seems natural.

It also makes me think that it would be nice to have an HP-like calculator that could use a separate alternative stack for programs and the solver. I like the unlimited stack, and my programs so far have returned the stack to how it was beforehand, but it would be nice if calculations (like the calculations that go on for sin/cos/tan etc..) happen off your stack, returning your answer to ST-X.

Actually, thinking about it more - couldn't you just take x, y, z and t off into a few registers, and then return afterwards? That way you won't lose your stack?

[Thomas Okken]

(10-27-2023 02:47 PM)dm319 Wrote:  couldn't you just take x, y, z and t off into a few registers, and then return afterwards? That way you won't lose your stack?

That's what FUNC is for.

In its current implementation, FUNC doesn't protect the stack from poorly-behaved functions in NSTK mode, but that will be fixed in the next release. So a function that starts with FUNC really will have its own stack, and can go crazy all it wants, without disturbing its caller's state.

https://thomasokken.com/free42/#programming

[Terje Vallestad]

(10-27-2023 05:34 PM)Thomas Okken Wrote:  That's what FUNC is for.

Good to see you back Thomas

[Thomas Okken]

(10-27-2023 06:20 PM)Terje Vallestad Wrote:  Good to see you back Thomas

Note that this not an endorsement of the lousy way I've been treated by mods on this forum; I just can't help myself from wanting to engage with Free42 and Plus42 users. We'll see how it goes.

But thank you :-)

[dm319]

(10-27-2023 05:34 PM)Thomas Okken Wrote:  That's what FUNC is for.

OMGoodness! This looks like a free42 feature - how great!

Honestly, recently I've come to really respect* what can be achieved with the HP UI. The softbuttons at the top, and that cleverness with inputting variables. I'm starting to get the hang of how the calculator differentiates between what is being inputted vs what you are asking to solve, and love that you can peek at variables.

To discover this func feature is yet more icing that I now need to try out.

Also, hello Thomas!

*In some previous posts I have been critical of the assembly-like language of the HP-42s. I do still think that we could improve on it with properly formatted code, if, for loops etc..

[dm319]

Oh my, just discovered LSTO!

[BruceH]

(10-27-2023 02:07 AM)MickM Wrote:  I really like this much better! Thoughts...

It's a nice layout and I like the way it means the left thumb can work a number of useful keys in the top-left quadrant. But I'm not sure that dedicating 4 keys to scale and unit prefixes is a good use of them (unless I've missed something and they do more).

In a similar vein, I don't enter pi nearly enough to make it worthwhile being a dedicated key. Perhaps it could be labelled i to do COMPLEX and pi be shifted divide?

But, if this ever became a physical keyboard, where would ON & OFF go and how do you choose up arrow when a menu is displayed?

[Thomas Okken]

(10-27-2023 09:56 PM)dm319 Wrote:  *In some previous posts I have been critical of the assembly-like language of the HP-42s. I do still think that we could improve on it with properly formatted code, if, for loops etc..

Or RPL. Not to achieve full HP-48/49/50 compatibility, that would be a huge task... but the basic language like it exists on the 48 could be supported in Plus42. Most of the required infrastructure is already there, the main missing pieces are an RPL-to-RPN compiler and a proper code editor.

(That's not an actual plan; just thinking out loud.)

[MickM]

A quick update - I have fixed the bugs dm319 found and also ran with his impression that EXIT right beside ENTER was awkward (which is true) to come up with the previously indicated layout. That layout is just so much more functional! It was also a lot more work than I thought :-(. I could attach everything for your consideration, however there is just one remaining hot-key definition giving me grief (for ⇧Delete) that I've asked Thomas to look at. The phone version is certainly ready to test. I'm going to wait a few hours to see what rabbit Thomas can pull out of his hat before providing new files (rather than releasing stuff in bits and pieces).

(10-27-2023 11:44 PM)BruceH Wrote:  I'm not sure that dedicating 4 keys to scale and unit prefixes is a good use of them (unless I've missed something and they do more).
...
In a similar vein, I don't enter pi nearly enough to make it worthwhile being a dedicated key.

I guess that depends on your field. Metric notation suffixes are so ubiquitously used in electrical/electronics engineering that providing those buttons was THE driver (along with the physical constants capability) for me making this skin. Same rationale for having π as it's own button and being as close as possible to the number 2 to make entering 2π as easy as possible. I absolutely acknowledge other fields don't share this usage universe. It was Thomas's first response when I also asked for a companion feature to display engineering notation numbers as ending in the single letter suffix e.g. display 1.23p instead of 1.23E-12. Other calculators (e.g. PCALC) have that capability so I was hoping to bend his arm for a creative way to implement that, say another entry in the DISP menu (similar to FIX/SCI/ENG) called MET (for metric notation) which would take the largest power of 10 for which you wanted a standard metric notation suffix shown IF you were currently using engineering notation. Anyway, his experience saw metric notation as "fringe" (very much counter to my experience) so at my urging he took the idea from off the table to something maybe near the bottom of his priorities - a small victory :-). Anyway, we all live in different worlds...

(10-27-2023 11:44 PM)BruceH Wrote:  But, if this ever became a physical keyboard, where would ON & OFF go and how do you choose up arrow when a menu is displayed?

I never had any thoughts/desires about this being a physical keyboard - this skin only allows screen menus to be selected by tapping on the screen itself, and even if a hardware version existed I'd never buy it IF the same thing was also available on my phone.

And on a separate note - I'm kind of curious in what anybody has thought about the CONST capability (on ⇧π). That is a really useful capability (for my field I guess) and yet all I've heard about it is crickets...

[MickM]

Updates have been posted and are available via the 1st post in this thread (where the latest version can now always be found).

Some focus areas include:

1. Confirmation of as many Windows and Linux hot-keys as you can manage - I'm unable to do that and it's where I expect the most issues.
2. Desktop app hot-key choices - I'm happy to entertain changes.
3. Desktop app bonus functions available via hot-keys (including other possible functions I could add for you).
4. Keyboard layout rearrangements. I'm mostly good with the buttons themselves, but some of the shifted functions could be moved around.
5. The operation and usefulness of the CONST program (including any hassles installing it)
6. Are the default constants on the first menu level the most appealing for a general audience?

OK - hopefully I've addressed most of the initial teething problems. I also kind of like how the numeric pad (especially on the Mac) works as a highly functional self-contained calculator. Looking forward to your help in making this skin as good as it can be :-).

[dm319]

(10-28-2023 01:08 PM)MickM Wrote:  I guess that depends on your field.

You'll never make everyone happy with a single layout I'm afraid! I think you should make what you think is best as you have clearly thought about this a lot, whereas someone like myself is just trying it out. PS do your colleagues use their phone mainly? Does anyone use a physical calculator?

shift-CONST is returning 'Nonexistent' for me I'm afraid.

(10-28-2023 09:06 AM)Thomas Okken Wrote:  (That's not an actual plan; just thinking out loud.)

A dangerous thing to do! I guess there is always that balance between something that is easy to input using a small grid of keys on a calculator, and the readability of something with structured programming. Do you think you could have a transpiler and code editor on the device, or are you thinking this is better on your PC?

[MickM]

(10-28-2023 06:21 PM)dm319 Wrote:  You'll never make everyone happy with a single layout I'm afraid!
... PS do your colleagues use their phone mainly? Does anyone use a physical calculator?

Totally agreed - I know all about not making people happy ;-)
I only know one person who uses a physical calculator these days, but only at his desk. The calculator is following the path of the typewriter (my opinion)!

(10-28-2023 06:21 PM)dm319 Wrote:  shift-CONST is returning 'Nonexistent' for me I'm afraid.

Are you referring to the desktop app, and/or the phone app?
On the Mac desktop app I place the gif, layout and CONST.raw files into:
~/Library/Application Support/Free42 (or Plus42)
and then from the File menu I do Import Programs... and locate/select the raw file and it's done.
On the phone app it's a different story and it depends on your platform (I'm using an iPhone). On the Mac I can edit CONST.txt, Select All, copy, and then on the iPhone Free42 app I can do a "GTO .." and go into PRGM mode, tap on the display to bring up the preferences and tap on Paste. There are other ways to also go about this, I was kind of hoping the people on this forum were the "grand masters" of such stuff. Either way, I refer you to:
https://thomasokken.com/free42/importexport.html

[Thomas Okken]

(10-28-2023 06:21 PM)dm319 Wrote:  A dangerous thing to do! I guess there is always that balance between something that is easy to input using a small grid of keys on a calculator, and the readability of something with structured programming. Do you think you could have a transpiler and code editor on the device, or are you thinking this is better on your PC?

On the device. Note that this is how the Plus42 PARSE function works already: it parses the equation, and then from the parse tree, it generates an RPN program.

RPL has very simple syntax, which makes it easy to parse. Code generation is generally a lot harder, but generating code for the Free42 / Plus42 RPN dialect is actually very easy, because it supports all the important constructs, like the dynamic RPN stack, deep RTN stack, and named local variables.

I wouldn't be surprised if writing a good code editor turned out be a greater challenge than writing an RPL-to-RPN compiler. Maybe I'll get into it and find out, once I'm happy with Plus42 and Free42 and don't have any other big stuff left on my to-do list.