Re: [WP 34S] New keyboard suggestion (NT ;-)



#21


#22

Having the windowing operations on different shift keys is not the best solution because you cannot hold a shift while tapping on UP/DOWN to move the window. I vote for moving <( and )> to g-shifted UP/DOWN.

h-shifted might be even better. Move MATRIX on h-6, leave STATUS on h-X and move ! and L.R. on the vacant f/g positions on the UP key. So no function is lost (L.R. still on the keyboard) and the function set should fit nicely (except that y^ and r are no longer together with L.R. We could just put them side by side.)

SB & CB may be disputable but they are better then x<>alpha. :-)

Edited: 10 Oct 2011, 4:16 a.m.


#23

I completely agree. I am still arguing for LASTx to replace FILL. RCL L can still function as LASTx, but FILL should be in P.FNC.

Ceterum censeo: Walter, bring back LASTx (and if you stubbornly refuse to, the community is going to do it the old HP way).


#24

What about putting a LastX label above the EEX key as a memory aide? We're not going to have a LastX command -- it will always display as RCL L. We don't have the hundred odd bytes to implement LastX as a stand alone command.


As for FILL, try working with the eight level stack -- FILL is far more useful there. If isn't g FILL vs ENTER ENTER ENTER. It is g FILL vs ENTER ENTER ENTER ENTER ENTER ENTER ENTER.

Additionally, FILL accepts a complex prefix so it is CPX g FILL versus CPX ENTER CPX ENTER CPX ENTER.


And as always, feel free to grab the sources and do what you want :-) That is the whole point of making this open source.


- Pauli


#25

Quote:
We're not going to have a LastX command -- it will always display as RCL L. We don't have the hundred odd bytes to implement LastX as a stand alone command.

I'll take your word for that since I have not looked at the code. Why LASTx replacing FILL would take 100s of "odd bytes" :-) is lost on me. Or why a key pointed to RCL L for that matter.
Quote:
As for FILL, try working with the eight level stack -- FILL is far more useful there. If isn't g FILL vs ENTER ENTER ENTER. It is g FILL vs ENTER ENTER ENTER ENTER ENTER ENTER ENTER.

Additionally, FILL accepts a complex prefix so it is CPX g FILL versus CPX ENTER CPX ENTER CPX ENTER.


I think there will be two camps, those that use FILL and the majority that do not outside of programming.
Quote:
And as always, feel free to grab the sources and do what you want :-) That is the whole point of making this open source.

I plan to, once I can fix my flashing problems. I'll try to setup a build environment on OS/X or Linux or *gasp* Windows in a VM.

#26

Egan, for the emulator, my preferred testing environment, you will need Windows anyway. Building the flash image on Mac OS shouldn't be too hard, Yagarto is available and the rest comes either with Xcode or is already there (like the Unix utilities or Perl.)

#27

Quote:
Why LASTx replacing FILL would take 100s of "odd bytes"

Replacing the "FILL" slot on the keyboard with "RCL L" won't cost anything much. It wouldn't look like "LASTx" in programs, it would look like "RCL L".

Creating a command named "LASTx" will take of the order of 100 bytes.


- Pauli

#28

Quote:
What about putting a LastX label above the EEX key as a memory aide?

Yes, this is a good idea.

#29

I wouldn't mind a LastX key (though it's operatively redundant) but please don't remove FILL, I use it often... And I use the 8-level stack.

Edited: 10 Oct 2011, 5:01 a.m.


#30

How about LASTx replacing FILL and RCL L = FILL?


#31

RCL L is just RCL of register L which serves as LastX, so there is no point in swapping the two functions. I'm discussing a user mode keyboard internally. If we get that straight, all should be fine for you.

#32

How would you then support RCL+ L or STO->L ???

Special casing RCL L creates a big inconsistency in the interface.


- Pauli

#33

please tell me you are being facetious...

#34

I disagree with adding LASTx. When RCL-L works just as well, I can't see wasting valuable keyboard real estate just to have a command on the keyboard twice to satisfy the nomenclature preferences of some.

Eric


#35

Quote:
wasting valuable keyboard real estate just to have a command on the keyboard twice

With this in mind, why not rethink the double assignment of 1/x, Sum+, x^2 and square root? I would suggest putting some of the more obscure functions on A-D that are not so terribly missed when A-D are in user mode: What about ||, %, delta% and ./,
The locations could be used for something else.

#36

Quote:
1/x, Sum+, x^2 and square root?

You missed the idea behind putting these as defaults on A to D: They are all on the keyboard in some other (shifted) position and the A to D location is just an unshifted shortcut to them if no program is active.

#37

I was aware of the idea behind it - and I like it. I still deem it at least worth of thinking about not having these shortcuts there but something else instead of twice the same.


#38

I tend to agree with this. There are several functions already that I never used because they're not my field, so I think that putting four "more obscure" functions there (but still having them in the catalogs of course) would free up 4 positions.

Cristian


#39

Hi Cristan, Alexander

Those four functions would have to be replaced by another four functions that are currently primary (e.g. un-shifted) functions. There are no other primary functions anyone would want put there (STO, RCL, roll, swap, neg, EEX, XEQ, CPX, -> /, *, +. -)

If I am going to be doing a lot of calculations that need them I just PSTO n (if I haven't already) and CLP and voila, they are back to being primary functions for A, B, C, D.

For the record, I'm fine with RCL L instead of LastX - at least I personally like it better than any of the alternatives.

BTW, why did ./, end up on the keyboard? I say put MATRIX there, make h-EXIT the OFF key and so be it.

While there are a few choices that Walter, Pauli and Marcus made that I didn't much like initially, I now find they make sense or are, at worst, inconsequential.

Edited: 10 Oct 2011, 1:39 p.m.


#40

Bonsoir Dominic,

Quote:
While there are a few choices that Walter, Pauli and Marcus made that I didn't much like initially, I now find they make sense or are, at worst, inconsequential.

(emphasis added). Please explain to me like a 4-year-old what you wanted to tell us with that.

Walter


#41

Dear 4-year old :-)
I didn't like having to f or g shift for trig and log functions - but now have gotten used to it. I glad you made that choice since it allows for programmable keys and some 60 functions on the keyboard due to 3 function keys.

What I'm trying to get across is that us users need to trust that you've thought carefully about your design decisions - even if we don't understand them initially.


#42

Merci bien - now I know your meaning of inconsequential :-)

#43

Quote:
Those four functions would have to be replaced by another four functions that are currently primary

I understand that they now are accessed unshifted when not in user mode. But why could they only be replaced by other primary functions? If you put a now shifted function on these keys, they would then be primary but why would that be a problem?


#44

because there are not any other primary functions that I would want to have to shift for when those labels are defined.

IMHO of course :-)


#45

I still don't understand the "primary" requirement. Why not putting there the four functions I suggested in #15 above?


#46

where are we going to move Sigma+ 1/x, y^x and sqrt to?


#47

Quote:
where are we going to move Sigma+ 1/x, y^x and sqrt to?

They are already there twice right now. That's the reason I came up with this idea in the first place.

Sum+ is on h/+

1/x is on f/ division key

y^x is on f/9

Square root is on f/times key

Edited: 11 Oct 2011, 11:31 a.m.


#48

I'm thoroughly confused.

I though you wanted to move those functions to other keys because you didn't want to shift to get Sigma+, 1/x, y^x and sqrt(x) when A-D was defined?


#49

No, I wanted to make room for functions that are not on the keyboard yet, instead of having four functions twice. See # 15 above.


#50

The four default primary functions top left were put there since they would have deserved top places but didn't make it on keytops else. When you overwrite one of them by defining e.g. label D, you will be happy to find an easy way to SQRT (the symbol) still. You don't want to dig for it in a menu, do you?

Walter


#51

That is why I did not want to get rid of them, but get rid of the 'obscure' functions (from the keyboard, I mean) I listed in posting #15 instead.


#52

Sorry, I will try to express it more clearly: The four top left default primary functions are four we are happy to feature as primary functions per default. When we'll overwrite one (or more) of them, we'll be still happy the respective (popular) function will be only two keystrokes away. IMHO we shall not put anything on this keyboard which will vanish with the first hotkey definition. YMMV.

#53

Oh, that's what you meant - don't know why I didn't get that.

Seems odd, though. To put the least popular functions currently on the keyboard in the most prominent place when LBL A-D are not defined.

My preference to achieve the same goal of freeing up shifted spaces on the keyboard would be to do away with the un-shifted A-D and make LBL A-D always (XEQ) shifted - kind of like the HP-15C.

I've been using the TVM solver a lot and when I go to change 'NP', 'NI' or 'I' I always forget to press XEQ first. As a result I find myself pressing XEQ for 'N', 'PMT' and 'FV'.


#54

I almost never use the functions indicated in white above A to D. I would not want to see the hot keys A to D replaced.

Be patient, please. The team is thinking... :-)


#55

Quote:
I almost never use the functions indicated in white above A to D. I would not want to see the hot keys A to D replaced.

Be patient, please. The team is thinking... :-)


Right, the hotkeys should not be replaced. I'd rather have two more... ;)
#56

Just to contradict myself, one of my flash banks has 4 optical power and frequency conversion routines mapped to A-D and I quite like the current design you came up with.

Hence my comment on another thread about adding a "USER" mode bit.

#57

Quote:
I've been using the TVM solver a lot and when I go to change 'NP', 'NI' or 'I' I always forget to press XEQ first. As a result I find myself pressing XEQ for 'N', 'PMT' and 'FV'.

Yippee, somebody is really using my TVM program? :-)

Yes, it would be much more comfortable to use with a full row of 6 user-defineable function keys - my biggest wish for the WP34s! ;-)

Franz


#58

Yes - it's really quite nice. I improved it's usability a bit by adding alpha labels to remind me what key I just hit. See the section in the users' guide

With six function keys it's going to be an HP-20b :-)

#59

:-D

Sounds like we must bring back x^y ...

#60

I like it. But: what about swapping Mode and Const? That way Conv and Const would be near each other, and I think they're somewhat related.
Also, why separate X.FCN and P.FCN? Again, I think they should be near eaach other, or even better (IMO) merged together.

I agree with Marcus about the window keys.

I like the move of OFF and the SF,CF keys.

I suppose it would be impossible to make the whole top row of keys assignable (like the first 4 are now)? That would give some more consistency to the layout, and increase the ease of use in hexadecimal mode. And I would just like to have a couple more programmable keys! And I don't use CPX or [Arrow] anyway... ;)

Cristian


#61

Quote:
I like it. But: what about swapping Mode and Const?

The letters CONST will not fit on those narrow top row keys. Otherwise I agree - perhaps we can use "CNST".


#62

But the letter K will surely fit.

There's a K key on the 10B, where it represents a constant-related function.

And K for Konstante is easy to remember.

There should be minimal confusion between such a key and the letter-K alphabet key, because those are all grey-shifted.

#63

MODE is put where it is since CPX and the two fraction labels are "setting the area" for modes there. Same reasons for ->, CONV, and R<>P on one key. And we feature a CPX CONST catalog which would give - following your suggestion - unfair advantage to Parkinson victims ;-/ We tried to avoid such double clicks.

#64

I second having windowing operations on different keys (same shift key)


Possibly Related Threads...
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 1,001 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 552 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  Prime Connectivity Kit Suggestion toml_12953 1 562 12-06-2013, 10:41 PM
Last Post: Michael de Estrada
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 794 12-04-2013, 11:14 AM
Last Post: Barry Mead
  HP Prime suggestion to avoid Numeric/Symbolic confusion Chris Pem10 4 696 11-19-2013, 05:49 AM
Last Post: bluesun08
  HP Prime - Revision Suggestion - Setting the Clock Bill Triplett 5 798 11-15-2013, 12:36 AM
Last Post: Joe Horn
  WP 34S/43 ?'s Richard Berler 3 707 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 733 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 959 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 994 11-08-2013, 01:28 PM
Last Post: Nick_S

Forum Jump: