SwissMicros Calculator Forum

Jaymos wrote: ↑

Sun Jul 28, 2019 7:47 pm

REG.ST or REG.S
BIT.ST or FLG.ST or BIT.S
?

What looks best on the faceplate? Perhaps R.ST / B.ST might work also - hints a bit louder about status?

Jaymos wrote: ↑

Sun Jul 28, 2019 7:47 pm

# is to change of integer number base.

Is # worthy enough of that front row seat? Otherwise we have a mathematical operation roaming about which would love to sit with its friends...

H2X wrote: ↑

Sun Jul 28, 2019 8:06 pm

Jaymos wrote: ↑

Sun Jul 28, 2019 7:47 pm

REG.ST or REG.S
BIT.ST or FLG.ST or BIT.S
?

What looks best on the faceplate? Perhaps R.ST / B.ST might work also - hints a bit louder about status?

Jaymos wrote: ↑

Sun Jul 28, 2019 7:47 pm

# is to change of integer number base.

Is # worthy enough of that front row seat? Otherwise we have a mathematical operation roaming about which would love to sit with its friends...

We probably have space for: RG.ST BT.ST on top of [8], but maybe not for REG.ST BIT.ST. I would check on the emulator which width sits best.

[#] definitely belongs there. It sits fine next to the other "number base" or "number format" things on the top line like ab/c d/c & d.ms & .d & h.ms. I like it.

Jaymos wrote: ↑

Sun Jul 28, 2019 8:15 pm

We probably have space for: RG.ST BT.ST on top of [8], but maybe not for REG.ST BIT.ST. I would check on the emulator which width sits best.

Good!

Jaymos wrote: ↑

Sun Jul 28, 2019 8:15 pm

[#] definitely belongs there. It sits fine next to the other "number base" or "number format" things on the top line like ab/c d/c & d.ms & .d & h.ms. I like it.

I follow the reasoning.

Well done!

Hello Jaco

The good thing about only three people discussing is that you can get through with three opinions. In the case of five people, there are already ten opinions.....

I think the last draft of the keyboard layout was very successful, I could immediately work productively with it . Of course, I still have a few comments and try to explain them as well as possible.

You already mentioned the exchange of SAVE and HOME.

Suggestion: I think you can rename DRG-> to TRANS(mute). I think that's what's being done here. Then R<- and ->P would be well lifted here again, like the 42S.

My opinion is: I think you really shouldn't have any stack and register operations on the cursor keys. This can lead to misinterpretations. I think you should find all stack manipulations on ENTER, RDOWN and x<>y. Then you might even get Walther excited about this keyboard layout, it's allowed to have dreams. For example, the free space on the cursor keys could be filled with a new functionality, jump to the first item / menu, jump to the last item / menu. Of course not yet, as this has not yet been defined and implemented.

My opinion is: As useful as the functions DROP and FILL are, I think they are mainly needed for programming. So it doesn't matter if you only find these functions in the menu. With the new HOME function, you can get to these menus very clearly.

Wish: Here I argue in the other direction. Even though you can solve LASTx via RCL L, I want to have LASTx directly on one button, old habits. I often use LASTx, RDOWN for example mostly only in programs.

Note: I don't like the CPX position, this menu could be set to g-ENTER, DROP is gone.....

Another urgent wish: Whenever there is a function and a menu on the shift keys, I would prefer to have the function always on f and the menu on g, even if the original functionality of the 42S would change from f() to g(). That wouldn't bother me at all. An example. With the 42S, the CLX is hidden in the CLEAR menu. If you want to cancel the number input because you find out that you are typing wrong, I don't have direct access to the CLX, as it still is with the 41C. I think the "Undo" function would behave like the CLX in such a situation, and you could easily reach it via f(<-).

So much for the topic right now.


Best regards Dani

Me again. I just read that you use FILL a lot. A possible keyboard configuration that could implement my suggestions compatible with your requirements:

f(COMPLEX), g(FILL ) to "ENTER".
f(LASTx), g(STK) to "x<>y".
f(DROP), g(MODE) to "CHS".
f(CNST), g(DISP) to "EEX", for symmetry reasons and probably because constants are used more often than switching the display.
f(<-|), g(CLR) to "<-" as already explained.

Under "Loss" of R<-, ->P and x!

@ H2X on Keyboard Layout in flux / platform cost savings re: yellow sprue / user friendly labeling / etc

inautilus wrote: ↑

Tue Jul 30, 2019 7:39 pm

@ H2X on Keyboard Layout in flux / platform cost savings re: yellow sprue / user friendly labeling / etc

Clever! I think I prefer the first one.

inautilus wrote: ↑

Tue Jul 30, 2019 7:39 pm

@ H2X on Keyboard Layout in flux / platform cost savings re: yellow sprue / user friendly labeling / etc

Definitely the first one that relates the key to the two faceplate colors!

Sorry about the poor resolution ... try this.

Dani R. wrote: ↑

Tue Jul 30, 2019 12:30 pm

Suggestion: I think you can rename DRG-> to TRANS(mute). I think that's what's being done here. Then R<- and ->P would be well lifted here again, like the 42S.

I think DRG-> can have a name change. I don't like TRANS though. Let's consider what we have:

The HP42S has CONV which does the degrees to rad conversion thing. But the 43S already has a CONV button, which does unit conversions.

I suggest that I change the unit conversions to [UNIT] and the deg>rad>grad>multi to [CONV].
So, [f][5] will then be UNIT, and [g][5] will be CONV.
How does that sound?

Wish: Here I argue in the other direction. Even though you can solve LASTx via RCL L, I want to have LASTx directly on one button, old habits. I often use LASTx, RDOWN for example mostly only in programs.

Note: I don't like the CPX position, this menu could be set to g-ENTER, DROP is gone.....

My opinion does not matter because I cannot add functions to the main project, and a Last x function on a button would need a new function which I can't add at this point. |(My opinion is I would like a button for last x).

Another urgent wish: Whenever there is a function and a menu on the shift keys, I would prefer to have the function always on f and the menu on g, even if the original functionality of the 42S would change from f() to g(). That wouldn't bother me at all. An example. With the 42S, the CLX is hidden in the CLEAR menu. If you want to cancel the number input because you find out that you are typing wrong, I don't have direct access to the CLX, as it still is with the 41C. I think the "Undo" function would behave like the CLX in such a situation, and you could easily reach it via f(<-).

I though about this one for a while and I mentioned that it is difficult for me to H2X before. I am finding [g][UNDO] difficult to handle.

I though of making [g] [UNDO] and I will reconsider it again after I can feel this one on the real calculator. I shift this issue to the 'to check later' list.