HP Forums
newRPL: proposal for Alpha mode - Printable Version

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: Not HP Calculators (/forum-7.html)
+--- Forum: Not quite HP Calculators - but related (/forum-8.html)
+--- Thread: newRPL: proposal for Alpha mode (/thread-3753.html)

Pages: 1 2


newRPL: proposal for Alpha mode - Claudio L. - 04-30-2015 04:42 PM

The blinking cursor in newRPL UI will be a letter. This way it will give back information to the user about the status of the command line/editor.
The command line editor has different modes of operation, which can be identified by the letter shown on the blinking cursor:

D = Direct execution mode. When in the stack, this is the initial mode. In this mode, most calculator keys will attempt to directly perform their actions. If there is text in the command line, it will be compiled first and put on the stack as if the Enter key was pressed, then the requested action will be executed. For example typing a number and pressing the INV key will leave the inverse of the number on the stack, without the need to press Enter first.

P = Programming mode. This mode is entered when the program delimiters are inserted, or the user manually switches into this mode. Most keys in this mode will append their commands to the command line instead of executing the command. This mode is useful for RPL programming.

A = Algebraic mode. This mode is used to enter algebraic expressions. The mode is entered automatically when the symbolic delimiters are typed, or the user manually switches into this mode. In this mode, keys will append the command to the command line without any separation, and commands will be entered as functions.

[[ so far, nothing new, these are the normal, PRG, ALG modes in the 50g, but instead of an annunciator in the status area, the letter in the cursor changes, this intro is needed only to understand what follows ]]

Proposal for the alpha key:
  • A single press and release of the Alpha key will activate/exit Alpha Mode (as in current single alpha-lock feature).
  • When in D, P or A modes, pressing and holding Alpha temporarily switches to Alpha Mode until the Alpha key is released. If no other key is pressed when Alpha is released, then Alpha works as if it was pressed and released, switching to Alpha mode until pressed again.
  • In temporary Alpha mode (while Alpha is being held), all keys will behave as if Alpha mode was active. This is used to quickly enter text when in other mode, without permanently switching to Alpha Mode back and forth (this provides functionality equivalent to single alpha press when double alpha locks is active).
  • When the Alpha Mode is activated, the cursor can be in any of the following modes: L = The keys will enter lowercase characters, C = The keys will enter uppercase characters, G = The keys will enter greek characters, g = The keys will enter lowercase greek letters. Initially, Alpha mode will enter L or C mode (whichever was used last).
  • Long-Pressing and releasing the Alpha key will toggle between L and C modes (or between G and g) (this is new).
  • Pressing and holding Alpha with other keys will temporarily toggle L/C (G/g) mode until released (this basically moves the left-shift functionality to the Alpha key) for the letter keys, may have other uses for other keys, for example for the numbers could insert subscript numbers, like A₁.
  • Pressing and holding Alpha, while pressing SPC will toggle between the latin (L or C modes) and greek (G or g modes) alphabets.
  • Left-Shift in Alpha mode is now free for other uses. For example to use the symbols that are printed on the keyboard like ≠, ≤ and ≥ (which currently cannot be accessed without leaving Alpha mode).

This is of course open to debate and discussion, so feel free to criticize... now is the time to have your voice heard, once this is implemented it will be set in stone.


RE: newRPL: proposal for Alpha mode - Helix - 04-30-2015 11:28 PM

(04-30-2015 04:42 PM)Claudio L. Wrote:  [*]When the Alpha Mode is activated, the cursor can be in any of the following modes: L = The keys will enter lowercase characters, C = The keys will enter uppercase characters, G = The keys will enter greek characters, g = The keys will enter lowercase greek letters. Initially, Alpha mode will enter L or C mode (whichever was used last).

Stupid question: why C, and not U?


Quote:[*]Pressing and holding Alpha with other keys will temporarily toggle L/C (G/g) mode until released (this basically moves the left-shift functionality to the Alpha key) for the letter keys, may have other uses for other keys, for example for the numbers could insert subscript numbers, like A₁

I don't understand this sentence (English is not my mother tongue). Could you reword it?

For the subscripts, I was thinking about a long press on the final key. For example, pressing the 1 key a second or so, would change the standard character to the subscript position. I can even imagine that continuing pressing that key would cycle through the various characters: standard – subscript –superscript – standard … and so on, until the key is released at the desired status.

(This feature could also be used elsewhere, to choose among several actions, provided that there is a visible change in the display, or a changing indicator is displayed. I'm thinking about the way digital watches work with only a few buttons, and a systematic usage of the long press to do the various choices and adjustments.)


RE: newRPL: proposal for Alpha mode - Claudio L. - 05-01-2015 02:09 AM

(04-30-2015 11:28 PM)Helix Wrote:  Stupid question: why C, and not U?
Ehhhhhh... I have no idea. C for capitals, I guess. There's no reason why it cannot be U.
This idea comes from the ZX Spectrum, in which the cursor was a blinking letter that changed according to context. L was lowercase, C for capitals, K for tokens, E for extended mode, and G for graphics mode, if my memory doesn't fail me. Why it was L and C and not C and S, or U and L, I have no idea. You'd have to ask Sir Clive Sinclair.
If anyone is interested, here it can be tested immediately. It starts in token mode K, but after the first token (just press J for example to get the LOAD command) it switches to L. Shift-2 toggles L and C, Ctrl-Shift goes into E mode for additional commands, and Shift-9 goes into G mode.
I always thought it was very clever to show information exactly where the eyes of the user are (at the cursor), rather than some indicator somewhere else.

(04-30-2015 11:28 PM)Helix Wrote:  
Quote:[*]Pressing and holding Alpha with other keys will temporarily toggle L/C (G/g) mode until released (this basically moves the left-shift functionality to the Alpha key) for the letter keys, may have other uses for other keys, for example for the numbers could insert subscript numbers, like A₁

I don't understand this sentence (English is not my mother tongue). Could you reword it?

Neither is mine, let me try that again.
The idea is that if you are let's say in programming mode, and you want to type the letter T for a variable name, instead of pressing Alpha to switch to alpha mode, then T, then Alpha again to be back in programming mode, you press and hold Alpha, then press T.
When you release both keys you are back in programming mode. If you want to type MYVAR while in programming mode, just keep Alpha pressed while you press M, then Y, etc... and when you release alpha, you are back in programming mode. It's harder to explain than it is to do it.

(04-30-2015 11:28 PM)Helix Wrote:  For the subscripts, I was thinking about a long press on the final key. For example, pressing the 1 key a second or so, would change the standard character to the subscript position. I can even imagine that continuing pressing that key would cycle through the various characters: standard – subscript –superscript – standard … and so on, until the key is released at the desired status.

(This feature could also be used elsewhere, to choose among several actions, provided that there is a visible change in the display, or a changing indicator is displayed. I'm thinking about the way digital watches work with only a few buttons, and a systematic usage of the long press to do the various choices and adjustments.)

Now this is an interesting idea. The keyboard driver right now doesn't support this, but it could be modified to issue a repeating long-press. This is interesting for several UI elements like combo boxes where you could cycle between elements.
For the numbers I'm not sure it would work well, because there's a conflict with the repeat feature on the keyboard. When you press and hold the number 1 you expect 11111111111111111111111..., rather than cycling sub/super/normal, but perhaps in some shifted plane it could work.


RE: newRPL: proposal for Alpha mode - rprosperi - 05-01-2015 03:00 AM

(04-30-2015 04:42 PM)Claudio L. Wrote:  The blinking cursor in newRPL UI will be a letter. This way it will give back information to the user about the status of the command line/editor.

A letter comprising the blinking cursor sounds like it could be distracting. Don't get me wrong, I like the idea; self-documenting UI components are intuitive and useful (assuming well thought-out, as this seems to be) however you're messing with something very fundamental. Is this UI mode optional?

I think a demo or test drive when the betas are ready would be essential to decide how intuitive vs. distracting this is. I look forward to driving this and hope it is as useful as it sounds.

This is another good example of how newRPL extends RPL without breaking the essence of what RPL is. Nice proposal.


RE: newRPL: proposal for Alpha mode - Claudio L. - 05-01-2015 03:10 PM

(05-01-2015 03:00 AM)rprosperi Wrote:  I think a demo or test drive when the betas are ready would be essential to decide how intuitive vs. distracting this is. I look forward to driving this and hope it is as useful as it sounds.

Did you notice I included a link to an online demo where you can see this cursor in action (in the original ZX Spectrum, now emulated in HTML5)? Check it out and see for yourself.


RE: newRPL: proposal for Alpha mode - Helix - 05-01-2015 08:10 PM

(04-30-2015 04:42 PM)Claudio L. Wrote:  The blinking cursor in newRPL UI will be a letter.

I think that the blinking cursor as a letter is a good idea. I am ready to adopt it.

I have no problem with the choice of letters for the cursor (C for capital, it's obvious now!)


(05-01-2015 02:09 AM)Claudio L. Wrote:  
(04-30-2015 11:28 PM)Helix Wrote:  
(04-30-2015 04:42 PM)Claudio L. Wrote:  •Pressing and holding Alpha with other keys will temporarily toggle L/C (G/g) mode until released (this basically moves the left-shift functionality to the Alpha key) for the letter keys, may have other uses for other keys, for example for the numbers could insert subscript numbers, like A₁.
I don't understand this sentence (English is not my mother tongue). Could you reword it?

Neither is mine, let me try that again.
The idea is that if you are let's say in programming mode, and you want to type the letter T for a variable name, instead of pressing Alpha to switch to alpha mode, then T, then Alpha again to be back in programming mode, you press and hold Alpha, then press T.
When you release both keys you are back in programming mode. If you want to type MYVAR while in programming mode, just keep Alpha pressed while you press M, then Y, etc... and when you release alpha, you are back in programming mode. It's harder to explain than it is to do it.

This explanation is very clear, but does not refer to the sentence I quoted above.
In fact, I understand there will be two different functions for pressing and holding the alpha key:
- when not in alpha mode, pressing and holding the alpha key will temporarily switch to alpha mode
- when in alpha mode, pressing and holding the alpha key will temporarily toggle between capital and lowercase letters.

It's hard to have a clear idea of how intuitive would be these key combinations only with words. I'm not sure it would be a vast improvement over the actual HP50g.


(05-01-2015 02:09 AM)Claudio L. Wrote:  For the numbers I'm not sure it would work well, because there's a conflict with the repeat feature on the keyboard. When you press and hold the number 1 you expect 11111111111111111111111..., rather than cycling sub/super/normal, but perhaps in some shifted plane it could work.

When I press and hold the number 1, I don't expect 11111111111, because:
- the hp50g doesn't work like that (and probably any other calculator)
- the same thing applies to letters
- I don't see the usefulness of this feature. If by accident I have to enter such a number, I must count the number of digits, so a keystroke for each is the right solution
- the subscripts (and superscripts?) should be accessible only in alpha mode


RE: newRPL: proposal for Alpha mode - Sukiari - 05-03-2015 09:40 PM

I don't like this idea. I think this is a perfect thing to put on the status line, not in the prompt itself. I think it could be distracting - if you move the cursor over another character, it will blink between the two?

If you put this information in the status line, along will all other status information, the user will always know where to look in order to determine their current mode. This is the simplest way.


RE: newRPL: proposal for Alpha mode - HrastProgrammer - 05-04-2015 05:02 AM

(05-03-2015 09:40 PM)Sukiari Wrote:  I don't like this idea. I think this is a perfect thing to put on the status line, not in the prompt itself. I think it could be distracting - if you move the cursor over another character, it will blink between the two?

Yes, this wouldn't be very nice. On Spectrum and ZX81 it worked because they are always in insert mode and the cursor is always positioned between two consecutive characters.

I actually like the idea of "self-describing" cursor because you don't have to have a status line so you can use the full display for editor. In my HRAST BASIC I have a solid cursor when the editor is in insert mode and a transparent cursor (blinking between a character and inverse-character) if it is in overwrite mode. Unfortunately, this doesn't cover uppercase/lowercase modes but I decided not to add a status line because full display for the editor was much more important to me.


RE: newRPL: proposal for Alpha mode - Claudio L. - 05-04-2015 01:18 PM

(05-04-2015 05:02 AM)HrastProgrammer Wrote:  
(05-03-2015 09:40 PM)Sukiari Wrote:  I don't like this idea. I think this is a perfect thing to put on the status line, not in the prompt itself. I think it could be distracting - if you move the cursor over another character, it will blink between the two?

Yes, this wouldn't be very nice. On Spectrum and ZX81 it worked because they are always in insert mode and the cursor is always positioned between two consecutive characters.

Correct, but having the cursor take physical space like in a Spectrum required redrawing the whole text line each time you move the cursor, so in this case it will be implemented like any other cursor, where it overlaps the text behind (although I always liked the way characters "flow" through the cursor in those old machines).

Yes, it will blink between two characters, except the cursor is always inverted!, So even if the character behind is identical, it will invert and blink.
Right now there's a blinking arrow, that appears and disappears in front of the text. What I'm proposing is a black rectangle with a letter inside, that appears and disappears in front of the text. From an arrow to something else is not a revolutionary change, I'd say it's about the same except it carries useful information.

(05-04-2015 05:02 AM)HrastProgrammer Wrote:  I actually like the idea of "self-describing" cursor because you don't have to have a status line so you can use the full display for editor. In my HRAST BASIC I have a solid cursor when the editor is in insert mode and a transparent cursor (blinking between a character and inverse-character) if it is in overwrite mode. Unfortunately, this doesn't cover uppercase/lowercase modes but I decided not to add a status line because full display for the editor was much more important to me.

That's exactly my point: we have 131x80 pixels only, and each pixel we can save is very valuable.


RE: newRPL: proposal for Alpha mode - Claudio L. - 05-04-2015 01:37 PM

(05-01-2015 08:10 PM)Helix Wrote:  When I press and hold the number 1, I don't expect 11111111111, because:
- the hp50g doesn't work like that (and probably any other calculator)
- the same thing applies to letters
- I don't see the usefulness of this feature. If by accident I have to enter such a number, I must count the number of digits, so a keystroke for each is the right solution
- the subscripts (and superscripts?) should be accessible only in alpha mode

You are right! I had to actually take the calculator and press and hold a number to test it. I assumed auto repeat was active (which means I never use it, otherwise I should know), but it's only for the cursors, backspace and delete. It makes perfect sense not having autorepeat, and that makes your idea incredibly useful. Long-press cycling is yet another useful way to use the keyboard. It complicates things from an implementation perspective since we'd have to store the state of each key and what it's inserting on the command line, so it can be "replaced" with the next item in the cycling list.

And thinking about it, it could have many uses. For example, in Alpha mode, you could press and hold the letter S, and it could cycle between S, SIN, ASIN, and Σ (all the symbols printed on the keyboard), in case you don't like to use Shifts.
This could eliminate the need for a "Greek" mode, making all greek letters available as one cycling option.


RE: newRPL: proposal for Alpha mode - Claudio L. - 05-04-2015 01:45 PM

(05-01-2015 03:00 AM)rprosperi Wrote:  A letter comprising the blinking cursor sounds like it could be distracting. Don't get me wrong, I like the idea; self-documenting UI components are intuitive and useful (assuming well thought-out, as this seems to be) however you're messing with something very fundamental. Is this UI mode optional?

I think a demo or test drive when the betas are ready would be essential to decide how intuitive vs. distracting this is. I look forward to driving this and hope it is as useful as it sounds.

You are correct, I need to put a demo out, it's too difficult to grasp how it looks or feels based on a verbal description.


RE: newRPL: proposal for Alpha mode - Claudio L. - 05-04-2015 02:01 PM

Here's a new proposal, in this case for Long-press, based on Helix's idea:
  • Autorepeat enabled only for cursors, backspace/Delete, SPC and perhaps Enter (any others?)
  • Long pressing a key (long press time is user configurable), begins cycling among certain choices until the key is released.
  • The list of choices should be user-configurable (not sure how yet, but doesn't matter).
  • When the first long press event happens, the choice should be displayed in the status area (or maybe a pop-up window?).
  • The long-press event auto repeats, cycling between the options at a constant pace.
  • The choice that was active at the time the key is released becomes active.
  • Without releasing the key, pressing the cursors (left/right or up/down?), would allow to quickly select the next/previous choice without waiting for the repeat time.
How does this one sound?


RE: newRPL: proposal for Alpha mode - Sukiari - 05-05-2015 06:49 PM

(05-04-2015 02:01 PM)Claudio L. Wrote:  Here's a new proposal, in this case for Long-press, based on Helix's idea:
  • Autorepeat enabled only for cursors, backspace/Delete, SPC and perhaps Enter (any others?)
  • Long pressing a key (long press time is user configurable), begins cycling among certain choices until the key is released.
  • The list of choices should be user-configurable (not sure how yet, but doesn't matter).
  • When the first long press event happens, the choice should be displayed in the status area (or maybe a pop-up window?).
  • The long-press event auto repeats, cycling between the options at a constant pace.
  • The choice that was active at the time the key is released becomes active.
  • Without releasing the key, pressing the cursors (left/right or up/down?), would allow to quickly select the next/previous choice without waiting for the repeat time.
How does this one sound?

I think that user-configurability is the key here. I for one would use a 'classic mode' that emulates exactly the cursor and entry style of my 48g / 50g.


RE: newRPL: proposal for Alpha mode - Helix - 05-05-2015 09:59 PM

(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.

(05-04-2015 01:37 PM)Claudio L. Wrote:  And thinking about it, it could have many uses. For example, in Alpha mode, you could press and hold the letter S, and it could cycle between S, SIN, ASIN, and Σ (all the symbols printed on the keyboard), in case you don't like to use Shifts.
This could eliminate the need for a "Greek" mode, making all greek letters available as one cycling option.

That could be an interesting possibility.

(05-05-2015 06:49 PM)Sukiari Wrote:  I think that user-configurability is the key here. I for one would use a 'classic mode' that emulates exactly the cursor and entry style of my 48g / 50g.

I agree with you, if newRPL could mimic the current HP50g, with much more speed and some additional features, it would be very appealing, but I think it will have a rather different interface:
http://www.hpmuseum.org/forum/thread-2100.html
http://a.fsdn.com/con/app/proj/newrpl/screenshots/20141030_191610.jpg

Maybe we are too conservative Smile


RE: newRPL: proposal for Alpha mode - Claudio L. - 05-06-2015 01:05 PM

(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 Smile

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.


RE: newRPL: proposal for Alpha mode - Helix - 05-07-2015 11:06 PM

(05-06-2015 01:05 PM)Claudio L. Wrote:  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:

Indeed, it will be much more configurable than I ever thought, and probably than I will ever need. But that's interesting. I find the context dependence an excellent idea, since sometimes I miss this feature or the 50g.

(05-06-2015 01:05 PM)Claudio L. Wrote:  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.

You are probably right, except that I'm still reluctant to adopt the Prime, but that's another story.


RE: newRPL: proposal for Alpha mode - Elite - 05-10-2015 12:45 PM

(04-30-2015 04:42 PM)Claudio L. Wrote:  
  • When the Alpha Mode is activated, the cursor can be in any of the following modes: L = The keys will enter lowercase characters, C = The keys will enter uppercase characters, G = The keys will enter greek characters, g = The keys will enter lowercase greek letters. Initially, Alpha mode will enter L or C mode (whichever was used last).


May I suggest using the aplha approach of the HP-42s for Greek letters.
It would eliminate the need to have to remember where exacly the Greek letter is located on the keyboard.

Suggestion for implementation:
Create a flag that can switch on the additional line of Greek letters above the function keys and conserve the traditional entry at the same time so that letters can still be entered through the keyboard.


RE: newRPL: proposal for Alpha mode - Helix - 10-11-2015 10:41 PM

I'm reactivating this thread to post my thoughts about the alpha mode in the current newRPL firmware.
I'm not sure it's an improvement compared to the 50g. I would say it's different, but not better. In fact, I still don't like the fact that the Alpha key activates the last used mode (capital or lower case letters). I'd prefer by far capital letters at the beginning.
In this case we would have:

In direct/program/algebraic modes:
press and hold ALPHA : temporary capital letters mode
ALPHA : activates the capital letters mode
double ALPHA : activates the lower case letters mode
triple ALPHA : no effect

In capital letters mode, if at least one letter has been entered in this mode:
press and hold ALPHA : temporary lower case letters mode
ALPHA : switches to the lower case letters mode
Double ALPHA : returns to the previous non alpha mode (Direct, Program or Algebraic)

In lower case letters mode, if at least one letter has been entered in this mode:
press and hold ALPHA : temporary capital letters mode
ALPHA : switches to the capital letters mode
Double ALPHA : returns to the previous non alpha mode (Direct, Program or Algebraic)

To me it would be more intuitive like that. If some users have different preferences, then I suggest making the choice available through a flag: first alpha press activates either the capital letters mode, or the last used alpha mode.

------------------------------------------------------------------------

In program or algebraic modes, is there a need to switch to the direct mode? I think it would be preferable here that the right shift ENTRY just toggles between algebraic and program modes, like in the 50g.

-------------------------------------------------------------------------

I've been thinking about Greek letters too. The proposal in the first post seems too complex for me.
The suggestion with the long press and cycling procedure as described above could be interesting. Another more conventional solution would be to simply use the left shift and right shift keys to enter lower case and capital Greek letters. This would be independent of the current alpha mode (capital or lower case letters).These characters are mainly used in mathematics and physics (apart from Greek users…), where we generally need only one character at once, and a direct access is important here, avoiding a mess of key presses.

The same is valid for underscripts and superscripts, which should be independent of the current alpha mode. So for example, in any alpha mode:
* pressing and holding the left shift key, and then pressing 0..9 would enter a subscript
* pressing and holding the right shift key, and pressing 0..9 would enter a superscript
I'm not sure that making the left shift key available for new uses is very interesting.

Just some thoughts.


RE: newRPL: proposal for Alpha mode - Claudio L. - 10-12-2015 02:36 PM

(10-11-2015 10:41 PM)Helix Wrote:  I'm reactivating this thread to post my thoughts about the alpha mode in the current newRPL firmware.
I'm not sure it's an improvement compared to the 50g. I would say it's different, but not better. In fact, I still don't like the fact that the Alpha key activates the last used mode (capital or lower case letters). I'd prefer by far capital letters at the beginning.

That can easily be accommodated.
The new alpha was not intended as an improvement, more of a reorganization, where the alpha key takes care of most functions that relate to alpha mode, and the shifts are left for other functions (more math related).

(10-11-2015 10:41 PM)Helix Wrote:  In program or algebraic modes, is there a need to switch to the direct mode? I think it would be preferable here that the right shift ENTRY just toggles between algebraic and program modes, like in the 50g.

I'm not sure so I cycled through all modes, but that can easily be changed as well.

(10-11-2015 10:41 PM)Helix Wrote:  I've been thinking about Greek letters too. The proposal in the first post seems too complex for me.
The suggestion with the long press and cycling procedure as described above could be interesting. Another more conventional solution would be to simply use the left shift and right shift keys to enter lower case and capital Greek letters. This would be independent of the current alpha mode (capital or lower case letters).These characters are mainly used in mathematics and physics (apart from Greek users…), where we generally need only one character at once, and a direct access is important here, avoiding a mess of key presses.

The same is valid for underscripts and superscripts, which should be independent of the current alpha mode. So for example, in any alpha mode:
* pressing and holding the left shift key, and then pressing 0..9 would enter a subscript
* pressing and holding the right shift key, and pressing 0..9 would enter a superscript
I'm not sure that making the left shift key available for new uses is very interesting.

I mostly agree, I scraped the Greek mode idea a long time ago. The only reason why the subscript/superscript numbers are the way they are now is because I was trying to keep some symbols in their traditional places, right-shift+number has a lot of symbols, some of which are actually printed on the keyboard (0 and 3), so moving symbols around could be a problem. I always find myself that shift and shift-hold are very easily confused, especially when I type fast, I tend to release the shift too late and do a shift-hold, so for those commonly used symbols, having them as shift AND shift-hold is important (example: the right arrow, commonly used in programming).
Are we willing to move infinity, # and the right arrow to get uniformity on the subscripts/superscripts?


RE: newRPL: proposal for Alpha mode - Helix - 10-12-2015 10:58 PM

Wow! I couldn't imagine that shift and shift-hold could be easily confused! I guess I'm much slower than you in typing on calculators…

I think it's better if mathematical symbols are not moved on the keyboard. That's the reason why I thought about the shift-hold access for subscripts and superscripts, but if you want that shift and shift-hold make the same thing, then my suggestion is not valid.