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

[Claudio L.]

(11-19-2015 11:54 PM)Helix Wrote:  

(11-19-2015 03:52 AM)Han Wrote:  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.

I have to read again the various ideas, but I think that this version of dual menu would be very convenient too.

My opinion on this idea is mixed. It's nice to be able to use F1-F6 for both menus, but then you can't really use them both at once, if you have to press a key to "switch", there's no difference with pressing VARS to use the variables, and PREV to go back, the way it is now.
Since you can only use one at a time, I don't see much advantage on displaying both at once on the screen, just press the switch key and you'll see the other menu.
It also fragments the status line. I think 2 lines and almost half the screen width is barely usable, and we can expand with pop-ups when we need more space. If you have one single line on top, the status area is much less usable/attractive, and we lose the option to expand it by covering the menu.

Now the second paragraph, where the second menu becomes a fully independent menu, not just variables, I do like. Once I do a generic menu framework I should be able to apply it to all keys, and have 2 fully independent menus, both active at the same time (no "switch" key).
However, we'll need a way to choose which menu will be targeted when you select let's say SYMB, or TIME. The switch key perhaps is a good idea, but the "current" selection only affects when a program wants to show a menu. F1-F6 will always be the top menu and G-L will always be the second menu.
Instead of the switch, perhaps we could make the menu change always affect the second menu, unless it's off. So to send a menu to the first one you'd have to use the VARS key to hide the second one, change the menu, then reactivate VARS. This way we save a key, but it seems cumbersome. This would make the top menu something you seldom change, and menu 2 changes all the time.
Any other ideas?