Indeed, two lines display of Free42 is limiting the value of pcm, and one needs a skin with dedicated custom buttons for meaningful usage - nevertheless, having pcm in Free42 would make possible for users to choose two lines display vs. pcm and one line display, and it would create a base for SwissMicros to offer that functionality in hardware too (DM42 has a multi-line display). Up to you of course, feel free to use the patch in Plus42, Free42 or bothThomas Okken wrote: ↑Sun Jan 30, 2022 10:34 amGreat, thank you! I'll take a look at it this week.
However, I am thinking of integrating this into Plus42, not Free42. I don't think having a permanent CUSTOM menu is very useful when you only have a two-line display. It's the extra space provided by the resizable display in Plus42 that got me interested.
DM42pcm-3.20.8 released
Re: DM42pcm-3.20.8 released
HP-15C, DM15L, HP-35S, DM42
-
- Posts: 1101
- Joined: Tue May 02, 2017 5:48 pm
- Location: Netherlands
- Contact:
Re: DM42pcm-3.20.8 released
Ljubo, Taking a look at your repo in GitHub, it looks like your entire patch is this. Is that correct?
Re: DM42pcm-3.20.8 released
Yes - that is the patch (I have formulated it also as a pull request here in a case a discussion is needed). By the way, I have built and tested it only on Linux.Thomas Okken wrote: ↑Wed Feb 02, 2022 1:12 amLjubo, Taking a look at your repo in GitHub, it looks like your entire patch is this. Is that correct?
HP-15C, DM15L, HP-35S, DM42
-
- Posts: 1101
- Joined: Tue May 02, 2017 5:48 pm
- Location: Netherlands
- Contact:
Re: DM42pcm-3.20.8 released
Ah, cool. Thanks!
Now that I'm looking at this, I wonder if this could be done in an even simpler manner. A few days ago, I added a new menu level, between mode_appmenu and mode_plainmenu, so make the UNITS and DIRS catalogs more useful, and I was a bit surprised how easy that change was.
(It feels a bit like I'm exploring someone else's code, but I wrote the menu system 17 years ago, and it has been virtually unchanged since then, and I have hardly looked at it at all in all those years, so I'm a bit foggy on the details!)
But it made me think: maybe it would be cleaner to implement the permanent CUSTOM menu in a similar fashion, by adding a seventh menu level, above mode_appmenu. This would have to be dealt with in get_front_menu() and maybe one or two other places, but not much else would have to change, I think. Even EXITALL could stay the same. And you wouldn't even need a special mode for permanent CUSTOM, since you could still get out of CUSTOM using EXIT, if you want unshifted access to SST and BST for programming.
The only tricky aspect I can see would be the behavior of Shift-2 and SF 27, because if they're going to activate CUSTOM by setting it at this new menu level, then it would override even application menus, and that's not OK, you should still be able to activate CUSTOM on top of application menus, and use EXIT to return to the application menu, without losing your place there. So I guess there would have to be a new command to activate CUSTOM in the new level, separate from activating CUSTOM in mode_plainmenu.
Now that I'm looking at this, I wonder if this could be done in an even simpler manner. A few days ago, I added a new menu level, between mode_appmenu and mode_plainmenu, so make the UNITS and DIRS catalogs more useful, and I was a bit surprised how easy that change was.
(It feels a bit like I'm exploring someone else's code, but I wrote the menu system 17 years ago, and it has been virtually unchanged since then, and I have hardly looked at it at all in all those years, so I'm a bit foggy on the details!)
But it made me think: maybe it would be cleaner to implement the permanent CUSTOM menu in a similar fashion, by adding a seventh menu level, above mode_appmenu. This would have to be dealt with in get_front_menu() and maybe one or two other places, but not much else would have to change, I think. Even EXITALL could stay the same. And you wouldn't even need a special mode for permanent CUSTOM, since you could still get out of CUSTOM using EXIT, if you want unshifted access to SST and BST for programming.
The only tricky aspect I can see would be the behavior of Shift-2 and SF 27, because if they're going to activate CUSTOM by setting it at this new menu level, then it would override even application menus, and that's not OK, you should still be able to activate CUSTOM on top of application menus, and use EXIT to return to the application menu, without losing your place there. So I guess there would have to be a new command to activate CUSTOM in the new level, separate from activating CUSTOM in mode_plainmenu.
Re: DM42pcm-3.20.8 released
My very first attempt was to "rewire" manu logic by simply changing "const menu_spec menus[]" in common/core_globals.cc and was thinking rest of the code is implemented in an "universal" way and menus variable defines the whole logic and hierarchy of menus - however, it didn't workedThomas Okken wrote: ↑Wed Feb 02, 2022 10:45 amAh, cool. Thanks!
Now that I'm looking at this, I wonder if this could be done in an even simpler manner.
Ideally there will be general handling of menus and a structure defining the whole hierarchy - where to go if one press "Exit", what are "higher level" menus that are accessible, etc. - similar to "const menu_spec menus[]". Also a state where there are no menus visible should be a "menu" that can be added to this kind of hierarchy. But, I assume that would be a larger rewrite.A few days ago, I added a new menu level, between mode_appmenu and mode_plainmenu, so make the UNITS and DIRS catalogs more useful, and I was a bit surprised how easy that change was.
(It feels a bit like I'm exploring someone else's code, but I wrote the menu system 17 years ago, and it has been virtually unchanged since then, and I have hardly looked at it at all in all those years, so I'm a bit foggy on the details!)
But it made me think: maybe it would be cleaner to implement the permanent CUSTOM menu in a similar fashion, by adding a seventh menu level, above mode_appmenu. This would have to be dealt with in get_front_menu() and maybe one or two other places, but not much else would have to change, I think.
BTW, in my implementation you can exit custom menu only in program mode, otherwise "Exit" will not exit the custom menu.Even EXITALL could stay the same. And you wouldn't even need a special mode for permanent CUSTOM, since you could still get out of CUSTOM using EXIT, if you want unshifted access to SST and BST for programming.
Looking forward to your changes, possibly I could merge it back to pcm version of free42 (although, I will be in the same dilemma - current system is working )The only tricky aspect I can see would be the behavior of Shift-2 and SF 27, because if they're going to activate CUSTOM by setting it at this new menu level, then it would override even application menus, and that's not OK, you should still be able to activate CUSTOM on top of application menus, and use EXIT to return to the application menu, without losing your place there. So I guess there would have to be a new command to activate CUSTOM in the new level, separate from activating CUSTOM in mode_plainmenu.
HP-15C, DM15L, HP-35S, DM42
-
- Posts: 1101
- Joined: Tue May 02, 2017 5:48 pm
- Location: Netherlands
- Contact:
Re: DM42pcm-3.20.8 released
Menu navigation is heavily dependent on context. The menus array as it is now encodes about as much of that hierarchy as I could manage. This covers the behavior of the application and plain function menus, but then you have three different flavors of temporary menus that can become active during command entry, and then there are VARMENU and CATALOG and the programmable menu, each with their own quirks.
I think keyboard handling could be cleaned up significantly, but I'm not so sure about menu handling...
That's basically what I'm suggesting, with the added menu level. I'll give it a go once the skins and GRAPH are done.
-
- Posts: 1101
- Joined: Tue May 02, 2017 5:48 pm
- Location: Netherlands
- Contact:
Re: DM42pcm-3.20.8 released
To clarify, the menu levels I'm talking about there are not levels in the directory hierarchy tree, but like transparent layers in which menus can be presented. Free42 has five of those layers, and I'm guessing the HP-42S uses something similar internally.Thomas Okken wrote: ↑Wed Feb 02, 2022 8:01 pmThat's basically what I'm suggesting, with the added menu level. I'll give it a go once the skins and GRAPH are done.
If there is an active menu in the top layer, it hides whatever menus may be active below it. And only if there is no menu active in any layer, do you see no menu on the screen.
Normally, the application menus (SOLVER, ∫f(x), MATRIX, STAT, BASE, and VARMENU) live in the bottommost layer, while the plain function menus live in the second layer from the bottom. When you activate a function menu on top of an application menu, it isn't added to any hierarchy, it is just activated in that second layer, and when you exit that menu, you'll see the application menu once again, because it was there the whole time, merely hidden by the function menu living in a level higher on the stack.
Each of the five levels has its own function, so menus aren't simply opened in whatever level happens to be free, but in whatever level is appropriate for the current use. So, function menus are always opened in the second layer from the bottom, which is why, after having switched from one function menu to another, EXIT will not take you back from that second menu to the first. The second menu has replaced the first within their layer.
So, adding another level to the stack of menu levels would be a very straightforward and clean hack to make CUSTOM appear when no other menus are active.
Also, this doesn't preclude opening CUSTOM in the plain-menu level. A menu may be open in more than one level at a time; for example, when you do CATALOG → PGM, and then press XEQ, you have the PGM catalog active in the plain-menu level and the command-menu level, or when you go into ALPHA mode and then press STO ENTER, you have the ALPHA menu upen in the alpha-menu and command-menu levels.
So, in summary, using an additional level at the bottom of the menu stack seems like a good solution for implementing permanent CUSTOM. And if showing that layer were conditional upon not being in PRGM mode — which could be achieved by simply adding an 'if' statement to get_front_menu(), I think — then it wouldn't get in the way too much, and you'd only have to use Shift-SST in RUN mode. And the visibility of the new layer could be controlled using a toggle switch in the MODES menu.