Too many labels for XEQ

Discussion around the Swiss Micros DM42 calculator.
User avatar
salvomic
Posts: 105
Joined: Sat Dec 30, 2017 10:09 am
Location: Ragusa, Sicily
Contact:

Re: Too many labels for XEQ

Post by salvomic » Mon Oct 12, 2020 10:46 am

firai wrote:
Mon Oct 12, 2020 10:33 am
...

Despite the length of my post, all of this hopefully wouldn't be too much work, and I look forward to seeing what comes out of this!
Very interesting suggestions, thanks for your contribute to this thread.

Salvo
∫aL√0mic (IT9CLU) :: DM42 (SN: 00881), DM41X (SN 00523), DM16, HP Prime, 50g, 41CX, 42s, 71b, 15C, 12C, 35s, WP34s -- Free42

firai
Posts: 23
Joined: Sun Sep 27, 2020 11:38 am
Location: NYC/HK

Re: Too many labels for XEQ

Post by firai » Wed Oct 14, 2020 3:09 pm

Thomas Okken wrote:
Sun Oct 11, 2020 7:57 pm
Agreed, 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!
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.

Here's a mockup of what I mean, done in Free42:
Image
Sam

Dave Britten
Posts: 100
Joined: Wed Jun 14, 2017 9:27 pm

Re: Too many labels for XEQ

Post by Dave Britten » Fri Oct 16, 2020 2:55 pm

Thomas Okken wrote:
Sun Oct 11, 2020 7:57 pm
rprosperi wrote:
Sun Oct 11, 2020 3:12 pm
Thomas Okken wrote:
Sun Oct 11, 2020 9:56 am
Hmm... Now that I'm working on some new functionality for Free42, maybe I should reconsider directories as well?
Whoa... 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.

Looking forward to see how this goes...
Agreed, 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:

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. ;)

firai
Posts: 23
Joined: Sun Sep 27, 2020 11:38 am
Location: NYC/HK

Re: Too many labels for XEQ

Post by firai » Fri Oct 16, 2020 3:29 pm

Dave Britten wrote:
Fri Oct 16, 2020 2:55 pm
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:

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. ;)
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.

What do the directory key labels look like on the 48? I was wondering how to fit an indicator in the existing menu keys, which was the only reason my second post and more complicated idea came about.

Thomas, out of curiosity, how are programs stored internally? Are they sequential pages as the existence of .END. would suggest?
Sam

Thomas Okken
Posts: 758
Joined: Tue May 02, 2017 5:48 pm
Location: United States
Contact:

Re: Too many labels for XEQ

Post by Thomas Okken » Fri Oct 16, 2020 3:52 pm

firai wrote:
Fri Oct 16, 2020 3:29 pm
What do the directory key labels look like on the 48? I was wondering how to fit an indicator in the existing menu keys, which was the only reason my second post and more complicated idea came about.
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!
firai wrote:
Fri Oct 16, 2020 3:29 pm
Thomas, out of curiosity, how are programs stored internally? Are they sequential pages as the existence of .END. would suggest?
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.

firai
Posts: 23
Joined: Sun Sep 27, 2020 11:38 am
Location: NYC/HK

Re: Too many labels for XEQ

Post by firai » Sat Oct 17, 2020 8:49 am

Thomas Okken wrote:
Fri Oct 16, 2020 3:52 pm
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.
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 pm
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!
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.
Sam

Thomas Okken
Posts: 758
Joined: Tue May 02, 2017 5:48 pm
Location: United States
Contact:

Re: Too many labels for XEQ

Post by Thomas Okken » Sat Oct 17, 2020 9:49 am

firai wrote:
Sat Oct 17, 2020 8:49 am
Thomas Okken wrote:
Fri Oct 16, 2020 3:52 pm
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.
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.
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 am
In your mind, do you want to just declutter the PGM menu or allow folders to have different namespaces with the change?
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.

Fortunately I have a lot of other work going on that I want to finish first so I have a lot of time to think about this (and listen to suggestions). The guiding principle is: I'd rather do a ton of extra work and get it right, than implement a simple but inelegant solution.

rprosperi
Posts: 989
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Too many labels for XEQ

Post by rprosperi » Sat Oct 17, 2020 2:48 pm

Thomas Okken wrote:
Sat Oct 17, 2020 9:49 am
The guiding principle is: I'd rather do a ton of extra work and get it right, than implement a simple but inelegant solution.
And this is exactly why Free42 is such a great product, has thrived for so long and continued to improve steadily. :D

Thanks for that!
--bob p

DM42: β00071 & 00282, DM41X: β00071, DM10L: 071/100

User avatar
PierreMengisen
Posts: 118
Joined: Wed Nov 29, 2017 1:38 pm
Location: Neuchâtel CH

Re: Too many labels for XEQ

Post by PierreMengisen » Sat Oct 17, 2020 7:40 pm

rprosperi wrote:
Sat Oct 17, 2020 2:48 pm
Thomas Okken wrote:
Sat Oct 17, 2020 9:49 am
The guiding principle is: I'd rather do a ton of extra work and get it right, than implement a simple but inelegant solution.
And this is exactly why Free42 is such a great product, has thrived for so long and continued to improve steadily. :D

Thanks for that!
+
Bob, you are definitely our spokesperson. ;)
Pierre
[TI59 with PC100C; TI-84 Plus CE-T; HP41CV with HP IL loop & 2*82161A DCD & 82162 TP; HP15C; HP28S; DM41; DM41L; DM42; DM41X]

User avatar
salvomic
Posts: 105
Joined: Sat Dec 30, 2017 10:09 am
Location: Ragusa, Sicily
Contact:

Re: Too many labels for XEQ

Post by salvomic » Sat Oct 17, 2020 10:32 pm

PierreMengisen wrote:
Sat Oct 17, 2020 7:40 pm
rprosperi wrote:
Sat Oct 17, 2020 2:48 pm
Thomas Okken wrote:
Sat Oct 17, 2020 9:49 am
The guiding principle is: I'd rather do a ton of extra work and get it right, than implement a simple but inelegant solution.
And this is exactly why Free42 is such a great product, has thrived for so long and continued to improve steadily. :D

Thanks for that!
+
Bob, you are definitely our spokesperson. ;)
++
I agree :)
∫aL√0mic (IT9CLU) :: DM42 (SN: 00881), DM41X (SN 00523), DM16, HP Prime, 50g, 41CX, 42s, 71b, 15C, 12C, 35s, WP34s -- Free42

Post Reply