newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[Han]

It's really hard to appreciate the dual menus because currently only one of them has any real tangible value (right now we have no menus for commands). Imagine paging through a few menus of commands, then having to go back to the variables as is currently the experience on the HP50G. Sometimes retrieving previous menus ([right shift] [nxt] on the HP48) works, sometimes it doesn't work as expected. Re-navigating through a few pages of command menus after accessing one's variables can become tedious. The dual menus would eliminate that issue.

A compromise (?)

That said, I am not so sure about using 6 additional keys for a secondary menu. That's 6 keys that are essentially "gone" unless they have different behaviors when the secondary menu is disabled. Part of me is interested in seeing only "half" of the secondary menu. It appears that nothing is really lost (auto-complete, etc) with a main menu and only 3 menu items for the secondary menu because everything can currently be displayed fully with only two rows at the bottom. This way, we still have VAR, STO, and NXT that could always behave as expected (NXT would work with the main menu). Here's an idea that came to me for the case of only "half" of the current secondary menu:

VAR - holding it would toggle the secondary menu. If the secondary menu is off, it behaves like regular VAR on the HP50G (variables are shown in the main menu). If the secondary menu is enabled, the VAR would act like NXT, but for the secondary menu, including the shifted versions. So LeftShift VAR would show the previous page, for example.

On losing 6 keys

Losing the HIST key means we have to "move" CMD and UNDO to something else -- a much harder problem (in my opinion) when keyboard real-estate has shrunk by 6 keys. We have already lost LASTARG via quick keystrokes (RightShift EEX on the HP48). The HIST command could actually be the LASTARG key (or some variation such as HIST being UNDO, and LASTARG being RightShift HIST). Don't forget that the transition from HP48 to HP50 saw the loss of a few main command menus. We also need a quick way to get to the custom menu and settings/modes screen. Then there is the issue of edit commands such as copy/paste. The HP50 has dedicated keys whereas the HP48 had an edit menu. I am ok without dedicated keys to editing, and actually prefer a simple keypress to quickly access an edit menu of sorts. Again, the issue would be: to what key would these actions be dedicated? The bigger picture, of course, is how we're going to quickly access the many menus of commands when there are fewer keys to dedicate toward those menus.

Also, losing "half" of the secondary menu is actually not as bad as it sounds, because when you have more than 6 variables, you actually only get 5 soft menus as the 6th one is the NXT key for the secondary menu.

Quote:since you'll never embrace the new keyboard layout or the new VARS menu unless you are forced to.

This is partially true. By default, the HP48 had graphical interfaces for things like plotting, etc. But I am willing to bet the farm that once users got to appreciate the soft-menu, many of them likely abandoned the slower graphical interfaces in favor of the soft-menus. By default, the HP50 forced algebraic entry on users. But how many of those who are in the audience with respect to newRPL do you think eventually embraced algebraic mode even though it was thrust upon them? On the other hand, making it optional means that those who want to venture out and try it, can. Once they start to see the benefits, then they are more likely to make the switch permanent. And this was how it was for the HP48 and HP50 with respect to graphical interfaces and ALG/RPN input.

Please correct me if I'm wrong, but my understanding of the secondary menu was that it provided a solution to the problem of wanting both a menu of commands _and_ variables visible and accessible at the same time. This is just a guess on my part. I too can appreciate the utility of having both menus available. However, am quite reluctant to give up six keys.

Yet another idea

Here's yet another idea that popped into mind while I am typing. Create two menus: a main one and a secondary one. Use a single key (maybe HIST or TOOL or something) to toggle the menu focus. Make the main menu on top, and the secondary menu on bottom. All keys affecting any menus (whether loading a menu or pressing NXT) would affect the currently focused menu (which would appear with black background so that it is clear to the user which one is in focus). Or you could even make the VAR key so that it behaves like NXT if the secondary menu is visible and presumably dedicated to variables (as proposed in paragraph 3). Error messages stay at the bottom, drawn over the menus. Create a single-row status area up at the top that can be used for things like auto-complete, time of day, path, memory, user mode, etc. This leaves the same amount of display area for the stack, since the current setup uses three rows at the bottom for menus.

The secondary menu doesn't even have to be dedicated to the variables. In fact, I think it would be even more useful to have the secondary menu be exactly that: a second menu. So if you wanted to, you could simply keep the second menu solely on variables. But you could theoretically could have, say, your variables and custom menu be your two menus, or say one menu show the matrix commands while another shows vector commands (i.e. two different categories). Having typed this, I am starting to think that having a menu dedicated to variables seems a bit restrictive.

EDIT: I just reread previous posts of mine relating to 2-mode menu systems. Insofar as TMENU is concerned, TMENU would work on whatever is the currently focused menu. We could tag the argument with :1: or :2: to specify manually which menu level to replace. The same for the MENU command.