Threaded Mode | Linear Mode

Claudio L. · 11-17-2015, 01:06 AM

(11-16-2015 04:45 PM)Han Wrote: Wait so does the OFF key work only in x49gp? or is it now working on the real hardware?

EDIT: Answered my own question with a firmware upgrade: Yes, OFF works in real hardware. But another question: what was it that was the key to getting OFF to work (just out of curiosity)

It wasn't a bug at all!
Here's the story:
To make things easier, I use Qt Creator as an IDE, even for cross compiling. As a side effect, my setup automatically added a compiler option -fPIE, which I wasn't aware of (it was nowhere in my project files).
This option was creating tables in a special section in the ELF file (.got tables), which weren't properly extracted into the ROM binary file (because they weren't supposed to be there in the first place).
So newRPL was working by miracle, many of the global variables were being redirected to ROM because they were "reading" this inexistent table.
Writing to ROM was working as RAM because the caches were enabled, so everything appeared to work fine on the surface.
I can't explain why the OFF function didn't work (I suspect the caches holding data supposed to be written to ROM had something to do with that), but removing that compiler option not only fixed the OFF function, but also my flash driver started communicating with the ROM chip properly, so it killed two in one shot.
I had been hunting that bug for months, and it turns out it wasn't a bug in my code, it wasn't even something I voluntarily added to the compiler.
I now added a few lines in the project file that remove all options that Qt Creator passes to the compiler without consent.

Another lesson learned the hard way.

Han · 11-17-2015, 01:28 PM

Glad you found the compiler flag that caused the problems! Seems crazy that the previous firmwares still worked with only cache memory available to it.

Some observations:
1. Typing in variable names leaves the on the stack without the ' mark (on the HP48, the ' mark would be displayed with the name)
2. ADD and + seem to be reversed on the HP48 (ADD treats lists like vectors whereas + catenates lists).
3. Typing ->col (leftarrow, not - followed by >) would result in an error. I was expecting ->col to be returned as an identifier since it is not a command (I am aware that ->COL is a command).
4. When the secondary menu is turned off, the APPS through NXT keys still behave as they were variable keys (in my opinion, they should not). Moreover the NXT key pages through the variables but I would expect this to affect the non-variable menu if the secondary menu is turned off.
5. Pressing [leftshift][NXT] pages through the variables up until the first page, but does not wrap around like [NXT] does after the last page.
6. Having [alpha] + up/down (while holding alpha) for autocompletion searches feels clunky. Tap [alpha] once for caps lock, and if you are a bit slow in pressing and holding alpha while using up/down, then the alpha mode switches to lower case.

Claudio L. · 11-17-2015, 02:09 PM

(11-17-2015 01:28 PM)Han Wrote: Glad you found the compiler flag that caused the problems! Seems crazy that the previous firmwares still worked with only cache memory available to it.

Thinking about it, that could also explain why the first boot after flashing a non-newRPL machine always crashed, while the second one worked. Unfortunately, I can't test this theory since my machine was already flashed.

(11-17-2015 01:28 PM)Han Wrote: Some observations:
1. Typing in variable names leaves the on the stack without the ' mark (on the HP48, the ' mark would be displayed with the name)

Quoted and unquoted variables are different objects. An unquoted variable that doesn't exist returns itself to the stack, and it's shown the way it is.

(11-17-2015 01:28 PM)Han Wrote: 2. ADD and + seem to be reversed on the HP48 (ADD treats lists like vectors whereas + catenates lists).

This was by design, discussed long time ago...

(11-17-2015 01:28 PM)Han Wrote: 3. Typing ->col (leftarrow, not - followed by >) would result in an error. I was expecting ->col to be returned as an identifier since it is not a command (I am aware that ->COL is a command).

This is by design (bad design, perhaps). When I started working on the symbolics engine, I decided to use the right arrow for rules (Mathematica style). From that moment, the right arrow became a symbolic operator and therefore it cannot be allowed in a variable or function name.
This is not good, as it's quite common to use the arrow in names. I'll have to revisit this and use a different operator for the rules (perhaps a composite like :→)

(11-17-2015 01:28 PM)Han Wrote: 4. When the secondary menu is turned off, the APPS through NXT keys still behave as they were variable keys (in my opinion, they should not). Moreover the NXT key pages through the variables but I would expect this to affect the non-variable menu if the secondary menu is turned off.

This is to be determined. We are going to need another NXT for the command menu, and turning off the VARS menu shouldn't change that. Perhaps NXT would become a duplicate of the other NXT, and STO a duplicate of HIST, but it might be too confusing.

(11-17-2015 01:28 PM)Han Wrote: 5. Pressing [leftshift][NXT] pages through the variables up until the first page, but does not wrap around like [NXT] does after the last page.

Easy fix, thanks for the bug report.

(11-17-2015 01:28 PM)Han Wrote: 6. Having [alpha] + up/down (while holding alpha) for autocompletion searches feels clunky. Tap [alpha] once for caps lock, and if you are a bit slow in pressing and holding alpha while using up/down, then the alpha mode switches to lower case.

I don't understand, pressing and holding alpha will switch the caps mode temporarily, if you press up/down it will always return to the mode you were before.
It will only change to lowercase if you press alpha and never press up/down or any other key.
The other shifts are used for navigation already. Any other keys where we could move autocomplete?

Han · 11-17-2015, 03:19 PM

(11-17-2015 02:09 PM)Claudio L. Wrote:
(11-17-2015 01:28 PM)Han Wrote: Some observations:
1. Typing in variable names leaves the on the stack without the ' mark (on the HP48, the ' mark would be displayed with the name)
Quoted and unquoted variables are different objects. An unquoted variable that doesn't exist returns itself to the stack, and it's shown the way it is.

Makes sense.

Quote:
(11-17-2015 01:28 PM)Han Wrote: 2. ADD and + seem to be reversed on the HP48 (ADD treats lists like vectors whereas + catenates lists).
This was by design, discussed long time ago...

I actually like the current design. It just seems more natural to have + do vector addition on lists.

Quote:
(11-17-2015 01:28 PM)Han Wrote: 4. When the secondary menu is turned off, the APPS through NXT keys still behave as they were variable keys (in my opinion, they should not). Moreover the NXT key pages through the variables but I would expect this to affect the non-variable menu if the secondary menu is turned off.
This is to be determined. We are going to need another NXT for the command menu, and turning off the VARS menu shouldn't change that. Perhaps NXT would become a duplicate of the other NXT, and STO a duplicate of HIST, but it might be too confusing.

When exactly 6 variables exist, then the NXT key behaves like a soft key, but when more than 6 variables exist then NXT behaves like regular NXT. I am not sure if I favor having NXT stay permanently as NXT, but it does make things more consistent. And in that same vein, I suppose we could make F6 behave like a separate NXT for the command menu.

Incidentally, when the VARS menu is turned off, and an error message is generated, the VARS menu is turned back on (after the error message goes away).

Quote:
(11-17-2015 01:28 PM)Han Wrote: 6. Having [alpha] + up/down (while holding alpha) for autocompletion searches feels clunky. Tap [alpha] once for caps lock, and if you are a bit slow in pressing and holding alpha while using up/down, then the alpha mode switches to lower case.

I don't understand, pressing and holding alpha will switch the caps mode temporarily, if you press up/down it will always return to the mode you were before.
It will only change to lowercase if you press alpha and never press up/down or any other key.
The other shifts are used for navigation already. Any other keys where we could move autocomplete?

I see now. It does indeed do exactly as you describe. I don't know why I didn't see it return to the previous mode.

Francois Lanciault · 11-17-2015, 05:26 PM

(11-17-2015 02:09 PM)Claudio L. Wrote:
(11-17-2015 01:28 PM)Han Wrote: Glad you found the compiler flag that caused the problems! Seems crazy that the previous firmwares still worked with only cache memory available to it.
Thinking about it, that could also explain why the first boot after flashing a non-newRPL machine always crashed, while the second one worked. Unfortunately, I can't test this theory since my machine was already flashed.

As I was never able to make newRPL boot on my machines so far (blank screen), I hope this new version will work. I will try it tonight.

François

Claudio L. · 11-17-2015, 07:03 PM

(11-17-2015 03:19 PM)Han Wrote: When exactly 6 variables exist, then the NXT key behaves like a soft key, but when more than 6 variables exist then NXT behaves like regular NXT. I am not sure if I favor having NXT stay permanently as NXT, but it does make things more consistent. And in that same vein, I suppose we could make F6 behave like a separate NXT for the command menu.

The original idea was to turn NXT into a soft-key freeing the key for other uses. The pro was one more key free to be reassigned, the con was that soft menus loose the 6th spot (unless exactly 6 items are present, that is). But at the time I thought having a dual menu compensated for the lost spot.
I'm open for change on this, but I like the fact that when you design an application with INFORM or so, you can choose to have exactly 6 options and use all spots.

(11-17-2015 03:19 PM)Han Wrote: Incidentally, when the VARS menu is turned off, and an error message is generated, the VARS menu is turned back on (after the error message goes away).

When you get the error, the text on the screen "jumps" to make room for the error message, but you kind of expect it. After a couple of seconds, the error disappear but you've already moved on to fix the error in the code. I tried it your way and didn't like the fact that the code "moved" on the screen right when I was trying to work on it, very distracting, so I left the second menu on after an error. I could change it and see what the feedback is, I personally found it better to not move the text unexpectedly.

Han · 11-17-2015, 09:08 PM

(11-17-2015 07:03 PM)Claudio L. Wrote: When you get the error, the text on the screen "jumps" to make room for the error message, but you kind of expect it. After a couple of seconds, the error disappear but you've already moved on to fix the error in the code. I tried it your way and didn't like the fact that the code "moved" on the screen right when I was trying to work on it, very distracting, so I left the second menu on after an error. I could change it and see what the feedback is, I personally found it better to not move the text unexpectedly.

These are perfectly valid points. Just thinking "aloud" : what about having error messages specifically appear up at the top, then? Unless the command line is multiple lines and spans the entire screen, the top of the screen is the stack. More likely an error message would not cover up anything but the stack and the screen should not ever have to jump. This would keep the error message behavior similar to that of the older HP48 series, too.

Speaking of errors, I managed to get the "Exception: Data abort" screen using:

{ + } 1 +

However, none of the menu options (Cont/Exit/Warmstart/Reset) seem to work; I had to use the reset hole -- which worked fine.

Claudio L. · 11-17-2015, 10:54 PM

(11-17-2015 09:08 PM)Han Wrote: These are perfectly valid points. Just thinking "aloud" : what about having error messages specifically appear up at the top, then? Unless the command line is multiple lines and spans the entire screen, the top of the screen is the stack. More likely an error message would not cover up anything but the stack and the screen should not ever have to jump. This would keep the error message behavior similar to that of the older HP48 series, too.

The editor can grow up and cover all the stack on large objects. While we could shrink the editor to make room for the error at the top, it will jump just the same when it disappears, as we'd have to shrink it back.
But, editing in full-screen mode is not so common, perhaps I'll do errors and popup messages on top when the VARS menu is off.

(11-17-2015 09:08 PM)Han Wrote: Speaking of errors, I managed to get the "Exception: Data abort" screen using:

{ + } 1 +

Good catch:
The + is an overloaded operator, which calls the handler of one of its operands. Turns out you are giving an overloaded operator as an operand, so the handler calls itself ad-infinitum, causing a nasty stack overflow.
I fixed it now. Operands cannot be overloadable operators, in that case it just calls the other argument handler, or does nothing if it's the only argument.

(11-17-2015 09:08 PM)Han Wrote: However, none of the menu options (Cont/Exit/Warmstart/Reset) seem to work; I had to use the reset hole -- which worked fine.

Stack overflow is really hard to recover from, since all routines use it. However, I just tested it and the options are working, but causing more and more exceptions because it keeps trying to read/write the stack beyond the available 4 kbytes.
Remember that Warmstart and Reset can only be activated with shift-hold (for safety).
Just do WarmStart several times until R15 doesn't change anymore, then hit Cont a few more times and it will do the Warmstart, you'll be back at the stack.

Claudio L. · 11-18-2015, 01:38 PM

(11-17-2015 07:25 PM)compsystems Wrote: 0: Is possible to install newRPL in the x49gp emulator?

Yes, there's a thread about that.

(11-17-2015 07:25 PM)compsystems Wrote: 1: Is possible to create a executable code of newRPL for PC?

Yes, since early this year, but you have to build from sources, as it hasn't been published in binary form yet. Just install Qt Creator and your compiler of choice, get the source code and open the project newrpl-ui.pro. Should go smooth from there.

Han · 11-18-2015, 03:00 PM

Would it be relatively easy to have OFF save the command line in the near future?

Claudio L. · 11-18-2015, 06:33 PM

(11-18-2015 03:00 PM)Han Wrote: Would it be relatively easy to have OFF save the command line in the near future?

Not easy, but it has to be done.
The current OFF implementation is just a proof of concept. I never developed the final version because it didn't work (until a few days ago).
The RPL OFF command needs to restore the complete RPL system and resume execution, with everything the way it was (screen, keyboard status, other hardware, command line, program execution, etc.).
That kind of framework needs some low-level magic.

Claudio L. · 11-18-2015, 10:30 PM

(11-17-2015 02:09 PM)Claudio L. Wrote:
(11-17-2015 01:28 PM)Han Wrote: 3. Typing ->col (leftarrow, not - followed by >) would result in an error. I was expecting ->col to be returned as an identifier since it is not a command (I am aware that ->COL is a command).
This is not good, as it's quite common to use the arrow in names. I'll have to revisit this and use a different operator for the rules (perhaps a composite like :→)

Done. Next release will allow variables to use the arrow.

Helix · (This post was last modified: 11-18-2015 11:05 PM by Helix.)

(11-17-2015 01:28 PM)Han Wrote: 4. When the secondary menu is turned off, the APPS through NXT keys still behave as they were variable keys (in my opinion, they should not).

I think this question has not been answered. When the secondary menu is turned off, will the APPS through NXT keys behave like in the 50g?
I'm still not sure I will adopt this new dual menu interface. I'm always tempted to use the STO key instead of the HIST key, and it's not very secure for me.

Claudio L. · 11-19-2015, 02:18 AM

(11-18-2015 11:04 PM)Helix Wrote:
(11-17-2015 01:28 PM)Han Wrote: 4. When the secondary menu is turned off, the APPS through NXT keys still behave as they were variable keys (in my opinion, they should not).

I think this question has not been answered. When the secondary menu is turned off, will the APPS through NXT keys behave like in the 50g?
I'm still not sure I will adopt this new dual menu interface. I'm always tempted to use the STO key instead of the HIST key, and it's not very secure for me.

I still don't know what to do with those keys when the menu is not there, so the answer was "to be determined".
I think using it like the 50g might be a step backwards, since you'll never embrace the new keyboard layout or the new VARS menu unless you are forced to.
I use newRPL at work almost every day, and sometimes I need a function that's not implemented yet, so I pull my "workhorse" 50g and I find myself pushing HIST instead of STO (quite frustrating).
Now I'm starting to get used to typing with Autocomplete, which needs that menu and status area to display the suggestion (I look for that suggestion all the time).
If you don't use the VARS menu, you'll also lose Autocomplete, the errors and popups need to take other space, etc.
I understand your reluctance to change, but I think the dual menu is the way of the future. As the UI progresses, it gets more difficult to live without it.

PS: I think the right arrow in the font should be shifted one pixel up. When used in an algebraic expression it looks too low. I tested with the new rules operator :→ and the arrow doesn't center between the dots very well. What do you think?

Han · (This post was last modified: 11-19-2015 03:26 PM by 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.

Francois Lanciault · 11-19-2015, 05:33 PM

Works now!!

Yeah!

(11-17-2015 05:26 PM)Francois Lanciault Wrote:
(11-17-2015 02:09 PM)Claudio L. Wrote: Thinking about it, that could also explain why the first boot after flashing a non-newRPL machine always crashed, while the second one worked. Unfortunately, I can't test this theory since my machine was already flashed.

As I was never able to make newRPL boot on my machines so far (blank screen), I hope this new version will work. I will try it tonight.

François

Claudio L. · 11-19-2015, 07:31 PM

(11-19-2015 05:33 PM)Francois Lanciault Wrote: Works now!!

Good to hear! thanks for reporting back.

Claudio L. · (This post was last modified: 11-19-2015 09:44 PM by Claudio L..)

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

There's plenty of room to relocate keys. For example: all numbers have menus. Shift-number shows the GUI menu, while shift-hold-number gives you the soft menu. newRPL doesn't have a need for this dual purpose, so all these keys become available.
Let's analyze what those keys are, whether it's justified to assign them a key and where to relocate them:

APPS: This is a super-menu to access other functions, most of them already have a dedicated key assignment. Just pick a seldom used item in this menu and relocate APPS there. For example, the TIME (number 9) function could be shift-9 and APPS could be shift-hold-9.
MODE: This doesn't deserve a key. Modes and Settings should be an item in the APPS menu.
TOOL: Quite useless, all functions here are readily accessible from the keyboard.
VAR: No need for it with dual menu.
STO: Relocated to HIST, I think it works fine there.
NXT: No need if NXT is a soft key.
BEGIN/END/COPY/CUT/PASTE: These only need to be active within the editor. We can keep them where they are, only active when Alpha mode is locked.
FILES: Could be an item in the APPS menu, or a shift-hold and a number.
CST: This one deserves its own key. I think long-press SYMB is a good candidate, or actually SYMB works as CST, then long-press SYMB brings the Symbolic menu.
Complex i: The symbol can stay where it is, but only active when in alpha mode. In normal mode, when it returns (0,1), it's hardly of any use, but could be in the complex soft-menu for easier access.
Given that (|) symbol: It's a symbol, so it can stay there, but only active when in Alpha mode.
UPDIR: This is very useful, we need to find a key for this one.
RCL: Shifted-HIST is fine I think;
PREV: No need, the NXT softkey provides this functionality when shifted.

So we only need to find new homes for APPS, FILES, and UPDIR, which shouldn't be too hard.
Also, we need a new home for CMD, which was displaced by RCL. I think left-shift Enter should do LASTARG (as usual) and left-shift-hold Enter should recall the last few command lines.
EDIT: UNDO can stay where it is, no need to move it.

Helix · (This post was last modified: 11-20-2015 12:00 AM by Helix.)

(11-19-2015 02:18 AM)Claudio L. Wrote: PS: I think the right arrow in the font should be shifted one pixel up. When used in an algebraic expression it looks too low. I tested with the new rules operator :→ and the arrow doesn't center between the dots very well. What do you think?

Yes, I agree with you. I've also noticed that some characters should be slightly modified too, for the same reason. I will fix that.

(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.

Han · 11-20-2015, 01:18 AM

Not sure if this is a bug worth reporting since OFF is not fully implemented, but if you press RightShift, and then press and hold the ON key only to release ON right around when hold-press would register, you can actually get the off sequence to flash off then back on.