newRPL: proposal for Alpha mode

[Claudio L.]

(05-05-2015 09:59 PM)Helix Wrote:  

(05-04-2015 02:01 PM)Claudio L. Wrote:  [*] The list of choices should be user-configurable (not sure how yet, but doesn't matter).

It's the most important point. Depending on the proposed choices, this feature can be more or less useful. In your description, I don't know if there is a connection with the previous discussion for the alpha key, or if each key will be configurable differently, like key assignments.

Perhaps I need to explain the intent with keyboard configurability. Here are some key points (some are not implemented yet, and subject to change). I hope this doesn't get too technical, but basically it makes keyboard MUCH more configurable than you ever thought:

• Custom keyboard definitions will be a single list of "key overrides". The format of the list is not well defined yet, but it will include the key code and shift plane, as well as a context number (will describe this next), and the action, which is typically a program or a string (with this "choices" new feature, I guess it will have to take lists too).
• The context number is an arbitrary number that describes where the user input is. For instance, #1 is the text editor, #2 is the stack, #3 could be the equation writer, etc. User programs will be able to define arbitrary context numbers for areas of their forms. This number does nothing, but key definitions only apply when the context number matches (Context #0 means a key definition applies to all contexts).
• There will NOT be a "user" keyboard mode. User keys are active 100% of the time. There will be a "safe" key combination that will disable custom definitions in case you mess up for example the Enter definition and your calc becomes unusable.
• Key definition lists will be stored like a variable, and searched for in the current dir, and then in upper directories same as any variable. The name will be a special name (I'm thinking ".KeyDef" or similar, or perhaps the first character should be a rare symbol so it doesn't get mixed with user variables).
• When the system looks for a key, the first match found is executed, and the search ends. This allows per-directory keyboard overrides.
• Key definition lists need ONLY contain overrides, if a key is not defined in any lists, its default system action will take place.
  

As a consequence of this, a user will be able to redefine a key or groups of keys without changing any system settings, just by storing its definition in a directory.
Think of applications, self-enclosed within their directories. They don't need to alter any system settings, just by the fact you enter the application directory, you automatically get its custom keyboard settings.
System-wide settings can go in the root directory, but may be overridden by other definitions inside directories.
Another new thing is the context. You can define a key to do something when in the command line editor, without interfering with its other functions. For example, it's easy to define the right cursor to do SWAP only when you are in the stack, just by putting the stack context number in the key definition.
On the 50g, to define something like that you needed a SystemRPL program to detect if you were in the stack or in the command line, and proceed accordingly, and even doing that, you had to also detect other things like if you are in PICT, etc or it wouldn't work properly. Now you only need one key definition with the simple << SWAP >> program.
An application will be able to freely alter this context within their forms. For example, a plotting application would have a form for data input, then another one where the plot is displayed. In the data entry, you set the context to a number, and create proper key definitions for it. Then the plot screen has a different context, where you can for instance override the cursors to move the cross-hair. You store all these definitions at once, in the same list, then just by changing the context you'll activate or deactivate certain keys.

(05-05-2015 09:59 PM)Helix Wrote:  Maybe we are too conservative

This community is averse to change, that is nothing new (the fact we are in a forum with the word "museum" in it should give a hint). But it's also relatively open to change once they can test it and get used to it. For instance most people hated the Prime at the beginning, but now you can see the same people in the Prime forums and they seem very happy with it.
So I expect some resistance to the new UI, but I think over time it will work. I use a 50g for daily work, if the new interface doesn't help me be more productive then it's not good and we'll be back at the original.
The proposed changes are merely incremental, nothing revolutionary here, picking the best features from UI's I've used in the past and trying to put it all together.
Time will tell.