Thoughts on User Mode

[Jacob Wall]

First, a short back story. I've been attempting to make the HP Prime my primary calculator for regular use, simple calculations mostly with some conversions between units and angular representation, etc. Until now, I was using the 50g in RPN mode quite efficiently for all of these requirements and I know there have been multiple posts about RPN mode limitations on the Prime already, but I'm re-opening this topic to come up with some possible suggestions on how to make this easier for myself, and of course many other potential users.

A. The User Keyboard appears to be a good candidate for customizing the calculator behaviour and implementing some handy functionality to be easily accessible. The problem is that the user can't do much in there and in my opinion expanding some of the basics would open many doors in this area. So how can this be done? I think two components are required.

1. Making the command/edit line accessible through PPL similar to System RPL commands such as:
   • EditLExists? - Flag indicating wheter an EditLine exists
   • RCL_CMD - Returns a copy of the current EditLine
   • DEL_CMD - Clears EditLine
   • CMD_PLUS - Inserts string into EditLine
     
   How would this be useful? A user key assignment could check if an edit line exists, if yes then perform some parsing and return some derived value, which could be a unit conversion, or anything really. If no edit line, then examine the stack history with Ans(x).
2. Make it possible to not just read Ans(x) history, but also write in order to delete, insert or append the stack. I know some will argue this is dangerous, but I would counter that this should be "user beware". One way to possibly keep a lid on the potential problems would be to limit deleting or adding only to the Level 1, which would make it easy for the system to protect against complex scenarios that may corrupt things. Probably even just two new commands here would do it:
   • DelAns1() - No argument, delete the last entry (Level 1) of the history, or do nothing if depth is zero, update screen, etc.
   • AppendAns(value) - Some value as argument, inserts into Level 1, update screen, etc.
     

B. Similar to how User key definitions are declared, a User Menu definition that would basically just be a label for the menu key, and pretty much identical "key" definition for the action. The Home view has no menu anyways, so a custom menu definition would be displayed if User Mode is set and such a definition is declared. Example code with proposed flag as described above:

Code:

// assign function to menu position 1
SOFTKEY M_1("Label")
BEGIN
  IF EditLExists? THEN
    // code to parse and handle command line
  ELSE
    // code to work with stack history
  END;
END;

For me, these suggestions would make this calculator far more interesting to use and customize, and because they are tucked into the User Mode, they wouldn't get in the way for those who don't want it or need it.

Thoughts? Good or bad ideas?

[salvomic]

IMHO definitely we need both, user key and user programmable softkey. It would be useful and more user-friendly to customise the calculator.
Also a contextual system of softkeys would be desirable for some functions, but I don't know if this is simple to implement in the Prime.

Salvo

EDIT: simply I mean a contextual softkey helper like that in the HP-42s, also programmable easily in the Prime...

[David Hayden]

To me, the user keyboard is of very limited value without the benefit of a keyboard overlay. It's impractical for someone to memorize the function of 10 or 20 or 60 (on the 50g) user key assignments.

One way to solve this is with something I've had on the back burner for a few years: a virtual keyboard overlay. The idea is that when you press the user key, the screen turns into a map of the keyboard (or perhaps just a part of the keyboard) that shows the user key assignments. Press a shift key and the map changes to the shifted assignments. When you select an assigned key, the original screen is restored and the assigned function executed.

I think I managed to prototype this on the 50g in userRPL. I've always thought it would make a great presentation at HHC.

[primer]

(12-17-2017 08:16 PM)Jacob Wall Wrote:  [list=1]
[*]Making the command/edit line accessible through PPL similar to System RPL commands such as:

• EditLExists? - Flag indicating wheter an EditLine exists
• RCL_CMD - Returns a copy of the current EditLine
• DEL_CMD - Clears EditLine
• CMD_PLUS - Inserts string into EditLine
  

why limiting on a line ?
It's now months I had in mind something like that :
object ENTRY, that would provide a full control of your entry.

ENTRY(0) would be the whole text, not only line, you can read or write with ENTRY(0):="a line\ntext";
ENTRY(1) would give col position of cursor (can also read or write)
ENTRY(2) would give row position of cursor
ENTRY(3) to return edit mode : 0=not editing 1=Text (like programs) 2=TextBook entry...
ENTRY(4) would be selection lenght (default 0, can also be read or write)
ENTRY(5) for managing flags (shift, alpha1, alpha...)

with such tool, one can implement features in existing tools.
like for example implementing a functions list inside program editor....

[Tim Wessman]

I would like to expose ability to create an editline for input and getting entries in a similar way to the current EDITLIST, EDITMAT, and a new EDITLINE (seems to be the best name).

I would love some feedback and design proposals from the community spelling out what you would like to see and how it would work. I wouldn't like to make a large number of commands to handle it, but with some clever thinking we can probably come up with some good solutions!

If you think you want to take a crack at designing this interface and input, now would be your time!

In addition, it is slated to redo completely the text printing to make it better to use. So changes or a new proposal unifying or improving TEXTOUT, TEXTSIZE, and PRINT to allow clean printing of formatted and non-formatted text, 2d vs non-2d, math objects, and similar would also be greatly appreciated and received at the moment!

[Jacob Wall]

(12-18-2017 05:00 PM)David Hayden Wrote:  To me, the user keyboard is of very limited value without the benefit of a keyboard overlay. It's impractical for someone to memorize the function of 10 or 20 or 60 (on the 50g) user key assignments.

Agreed, for myself I would only want a handful of key assignments (at the most) that I could easily remember, but having another 6 as a menu would be very useful and eliminate need for memorization.

[Jacob Wall]

(12-18-2017 10:33 PM)primer Wrote:  why limiting on a line ?
It's now months I had in mind something like that :
object ENTRY, that would provide a full control of your entry.

ENTRY(0) would be the whole text, not only line, you can read or write with ENTRY(0):="a line\ntext";
ENTRY(1) would give col position of cursor (can also read or write)
ENTRY(2) would give row position of cursor
ENTRY(3) to return edit mode : 0=not editing 1=Text (like programs) 2=TextBook entry...
ENTRY(4) would be selection lenght (default 0, can also be read or write)
ENTRY(5) for managing flags (shift, alpha1, alpha...)

with such tool, one can implement features in existing tools.
like for example implementing a functions list inside program editor....

Interesting ideas, that would create a far wider range of potential applications certainly.

[Jacob Wall]

(12-20-2017 01:30 AM)Tim Wessman Wrote:  I would like to expose ability to create an editline for input and getting entries in a similar way to the current EDITLIST, EDITMAT, and a new EDITLINE (seems to be the best name).

I would love some feedback and design proposals from the community spelling out what you would like to see and how it would work. I wouldn't like to make a large number of commands to handle it, but with some clever thinking we can probably come up with some good solutions!

If you think you want to take a crack at designing this interface and input, now would be your time!

In addition, it is slated to redo completely the text printing to make it better to use. So changes or a new proposal unifying or improving TEXTOUT, TEXTSIZE, and PRINT to allow clean printing of formatted and non-formatted text, 2d vs non-2d, math objects, and similar would also be greatly appreciated and received at the moment!

Great news, I'll certainly give this some further thought.

[Carlos295pz]

I would like to collaborate with the EDITLINE but I do not understand the objective very well

[Giancarlo]

Is the EDITLINE command supposed to edit an object bringing the user to the command line or define a new environment like the EDITLIST command does?

If formatting is a must maybe an environment like the NOTES is better.

I am interested in this command.

Thanks

Giancarlo

[primer]

(12-21-2017 08:27 AM)Giancarlo Wrote:  Is the EDITLINE command supposed to edit an object bringing the user to the command line or define a new environment like the EDITLIST command does?

If formatting is a must maybe an environment like the NOTES is better.

I am interested in this command.

Thanks

Giancarlo

For my part, I had in mind an object that could interact with what you are editing (that could be a program in its environment, a command line in CAS or home... a formula, a note...)
The object could be used in "user mode" scope.
Possible interactions could be read and write what you are editing, altering selection, changing cursor location....

example of usage, let's say you create user key shift [+] with the following function :
- read what you are editing as a string (let's says you are in program editor).
- in this string, find every functions, display a list of these functions,
- when user choose one of these function, modify the cursor position to move to the choosen function.
Ok, it's not easy, but I can see a lot of feature we could add like this

note : we also need to know in which environment we are (program editor, home entry, notes...)

[StephenG1CMZ]

(12-20-2017 02:59 AM)Jacob Wall Wrote:  

(12-18-2017 05:00 PM)David Hayden Wrote:  To me, the user keyboard is of very limited value without the benefit of a keyboard overlay. It's impractical for someone to memorize the function of 10 or 20 or 60 (on the 50g) user key assignments.

Agreed, for myself I would only want a handful of key assignments (at the most) that I could easily remember, but having another 6 as a menu would be very useful and eliminate need for memorization.

I do like the idea of being able to see the user's key definitions.

On the virtual calculators, it should be relatively easy to change the key displays, and that would greatly improve the usability of specialised user keys to customise the interface.
On the real hardware, the same information could show up either in a DRAWMENU line or in a CHOOSE list.
I have previously suggested something similar but without showing the user key text: http://www.hpmuseum.org/forum/thread-659...t=drawmenu -
Just changing the key colour to indicate which keys the user can use in a program.
But including the user definitions too is far more useful.

[Eddie W. Shore]

(12-18-2017 05:00 PM)David Hayden Wrote:  To me, the user keyboard is of very limited value without the benefit of a keyboard overlay. It's impractical for someone to memorize the function of 10 or 20 or 60 (on the 50g) user key assignments.

One way to solve this is with something I've had on the back burner for a few years: a virtual keyboard overlay. The idea is that when you press the user key, the screen turns into a map of the keyboard (or perhaps just a part of the keyboard) that shows the user key assignments. Press a shift key and the map changes to the shifted assignments. When you select an assigned key, the original screen is restored and the assigned function executed.

I think I managed to prototype this on the 50g in userRPL. I've always thought it would make a great presentation at HHC.

I like this idea.

[Gene222]

(12-20-2017 02:59 AM)Jacob Wall Wrote:  

(12-18-2017 05:00 PM)David Hayden Wrote:  To me, the user keyboard is of very limited value without the benefit of a keyboard overlay. It's impractical for someone to memorize the function of 10 or 20 or 60 (on the 50g) user key assignments.

Agreed, for myself I would only want a handful of key assignments (at the most) that I could easily remember, but having another 6 as a menu would be very useful and eliminate need for memorization.

The toolbox key provides quick access to some functions and commands, but the list is quite limiting, and its catalog access is too slow. How about providing a user definable menu for functions and commands under the toolbox key?

If you only have a handful of key assignments, Eddie Shore's "User Key: Custom Menu" program is a nice alternative. Instead of using key assignments to access functions and commands, the program is menu driven and will type the function or command into the command line. It is simple and makes the HP Prime much more usable. Thank you Eddie!

2/26/18 EDIT. Ignore my comment. I did not realize you were talking about HP Prime programming language to create and use menus and key assignments.