Very interesting suggestions, thanks for your contribute to this thread.
Salvo
Very interesting suggestions, thanks for your contribute to this thread.
Here's another unsolicited possible idea for navigating folders, in case you wanted any: if there isn't enough space to show all of the relevant information with menus, would it be possible to use the format and scrolling capabilities provided by the program editor? This sort of interface could possibly be entered through a menu button to supplement the usual method.Thomas Okken wrote: ↑Sun Oct 11, 2020 7:57 pmAgreed, the UI is a bigger challenge than the actual functionality. I may have to add a few keys to keep things from getting too cluttered!
How about something simple? Maybe add a "DIR" instruction that collapses all of the global labels between the "DIR" and the next "END" or "DIR" into a submenu? For example:Thomas Okken wrote: ↑Sun Oct 11, 2020 7:57 pmAgreed, the UI is a bigger challenge than the actual functionality. I may have to add a few keys to keep things from getting too cluttered!rprosperi wrote: ↑Sun Oct 11, 2020 3:12 pmWhoa... now THAT would be interesting, if as Didier notes, it can be achieved without excessive work. I think the main challenge would be to incorporate this into into the UI in an intuitive way, though I'd guess that the challenges of navigating folders on all the various platforms is also fairly daunting.Thomas Okken wrote: ↑Sun Oct 11, 2020 9:56 amHmm... Now that I'm working on some new functionality for Free42, maybe I should reconsider directories as well?
Looking forward to see how this goes...
This seems similar to what I was trying to achieve with the "master-slave" idea in my first post, but probably simpler to implement and perhaps more intuitive to use in a program if everything you're trying to hide is in the same program.Dave Britten wrote: ↑Fri Oct 16, 2020 2:55 pmHow about something simple? Maybe add a "DIR" instruction that collapses all of the global labels between the "DIR" and the next "END" or "DIR" into a submenu? For example:
01 LBL "TVM"
02 DIR "TVMFUNC"
03 LBL "N"
04 LBL "I%"
05 LBL "PV"
06 LBL "PMT"
07 LBL "FV"
08 END
The XEQ/GTO menu would only show "TVM" and "TVMFUNC". Pressing "TVMFUNC" would open another menu with "N", "I%", "PV", "PMT", and "FV". Pressing EXIT at the submenu would go back to the XEQ menu, and selecting any of the programs in the "TVMFUNC" directory would close the menu like usual. Any of the labels could still be keyed in at any time via the alpha keys. Multiple "DIR" instructions in a program would create multiple directories in the XEQ/GTO menu, not create nested directories. This wouldn't require the complexity of implementing an actual hierarchical filesystem, but would still give the ability to clean up the XEQ/GTO menu for calculators with lots of programs. And best of all, you could make the directory key labels look like little folders, like on the 48.
Directories on the 48 are distinguished in the VAR menu by having a little tab sticking out of the top of the menu label. It's just a little one-pixel-thick line segment, but it is effective. This is what I'm envisioning as well, although the situation is a bit more complicated when grafting directories onto the 42S architecture, because unlike the 48, it has separate name spaces for programs and variables. So the directories would probably have to appear in the PGM and variable menus... it's a bit of a puzzle!
Yes, they are stored as a sequence. The ordering matters for how they are displayed in the PGM catalog, and for global label searches, which go backwards from the .END. to the beginning of program memory.
Like a short line segment on one side at the top to imitate a tab? I previously thought about this, but I (erroneously) thought that space is so tight that it would interfere with descenders from the top line by the time the tab is big enough to be clearly visible.Thomas Okken wrote: ↑Fri Oct 16, 2020 3:52 pmDirectories on the 48 are distinguished in the VAR menu by having a little tab sticking out of the top of the menu label. It's just a little one-pixel-thick line segment, but it is effective.
In your mind, do you want to just declutter the PGM menu or allow folders to have different namespaces with the change? It seems like Dave's idea or my master-slave idea could be implemented to achieve the former without any changes to the underlying storage mechanism for program code or how it gets executed. The only change would be how the kernel parses the code listings to generate the PGM/XEQ/GTO catalog (as far as I can tell from draw_catalog and rebuild_label_table). This of course means that programs in different "directories" (as how the user sees them) still shouldn't have conflicting names if they need to be called by other programs, and variables used by programs across directories still all live in a common namespace. I assume actually achieving different namespaces would be much more difficult to implement.Thomas Okken wrote: ↑Fri Oct 16, 2020 3:52 pmThis is what I'm envisioning as well, although the situation is a bit more complicated when grafting directories onto the 42S architecture, because unlike the 48, it has separate name spaces for programs and variables. So the directories would probably have to appear in the PGM and variable menus... it's a bit of a puzzle!
There is one pixel of empty space above the menu labels. The tabs do touch descenders from the bottom line, but they do not overlap. See here for an example; note that the same convention is used to indicate submenus on the 48.firai wrote: ↑Sat Oct 17, 2020 8:49 amLike a short line segment on one side at the top to imitate a tab? I previously thought about this, but I (erroneously) thought that space is so tight that it would interfere with descenders from the top line by the time the tab is big enough to be clearly visible.Thomas Okken wrote: ↑Fri Oct 16, 2020 3:52 pmDirectories on the 48 are distinguished in the VAR menu by having a little tab sticking out of the top of the menu label. It's just a little one-pixel-thick line segment, but it is effective.
The latter. I'm not too worried about the code changes that will be required under the hood; they won't be trivial but I've performed similar surgery to implement LSTO and SST→ so it's familiar ground. Figuring out the UI and the additional functions will be the interesting part.
And this is exactly why Free42 is such a great product, has thrived for so long and continued to improve steadily.Thomas Okken wrote: ↑Sat Oct 17, 2020 9:49 amThe guiding principle is: I'd rather do a ton of extra work and get it right, than implement a simple but inelegant solution.
+rprosperi wrote: ↑Sat Oct 17, 2020 2:48 pmAnd this is exactly why Free42 is such a great product, has thrived for so long and continued to improve steadily.Thomas Okken wrote: ↑Sat Oct 17, 2020 9:49 amThe guiding principle is: I'd rather do a ton of extra work and get it right, than implement a simple but inelegant solution.
Thanks for that!
++PierreMengisen wrote: ↑Sat Oct 17, 2020 7:40 pm+rprosperi wrote: ↑Sat Oct 17, 2020 2:48 pmAnd this is exactly why Free42 is such a great product, has thrived for so long and continued to improve steadily.Thomas Okken wrote: ↑Sat Oct 17, 2020 9:49 amThe guiding principle is: I'd rather do a ton of extra work and get it right, than implement a simple but inelegant solution.
Thanks for that!
Bob, you are definitely our spokesperson.