43S Alternative key layout --> WP43C

[H2X]

Enjoy! And then think about your potential users suffering from Parkinson ...

Heaven forbid! I say we leave them to you...

[Dani R.]

The short twice press to get the g button ...

Apologies if I don't understand you correctly, but I was not suggesting to change the original, three-state shift key cycle which I suggested way back in another thread. I am totally happy with how that has played out.

My mistake, I naturally meant pressing twice briefly f/g-key to get the shift state g. But I think this should be clear now.

EDIT: why not press three times short for g[FN], like when calling HOME? To be honest, I can't call HOME 100%, but that doesn't matter here. For [FN], f[FN], g[FN] pressing it three times seems too fiddly to me.

This would be triple-pressing, right - but you are trying to rule it out, aren't you? Or am I misunderstanding you completely?

Exactly, for normal function calls you should not use triple-pressing.

[Guenter]

I have created a simple overlay for the DM42 flashed as WP43C, as I've done for the WP43S. Get this PDF: https://drive.google.com/file/d/167ZvHG ... sp=sharing and print it on normal paper. Then cut off the paper above and below the faceplate. Now wrap the remaining paper around your DM42, apply some scotch tape and your done. Far from being perfect but usable to find the right keys when exploring the WP43C on a DM42.

Günter

[Jaymos]

Thank you for the think tank. I like the good discussion on this topic.

My opinion is as follows:

1. I do not want the confirmation short presses as per my previous sketch anymore. I think that rprosperi is right that too many clicks is looking for trouble.

2. I also want to say, that this is an experimental platform, and I am willing to try different bits.

3. We don't have to decide on one solution only. Options that are not clashing, can co-exist. And a config flag is not a problem either.

I definitely think the f/g option can stay as base level control any way. There is no reason why the f/g cycle on the shift should change with the options discussed.

As a technical point, the way I want to hack it into the system is that whichever shift method will still activate the internal shiftF and shiftG flags, and then execute FN normally as if you pressed shift. That is what the shift cycle hack is doing already. The WP43S system will care for the correct dispatch. That way the dispatch function remains centralised and has common upgrades from Martin in future.

4. I like H2X's proposal:

1. Press (display FN1) + release = execute FN1 (the normal, short press function).
2. Press (display FN1) + hold (display f(FN1)) + release = execute f(FN).
3. Press (display FN1) + hold (display changes to f(FN1)) + hold (display changes to g(FN1)) + release = execute g(FN).
4. Press (display FN1) + hold (display changes to f(FN1)) + hold (display changes to g(FN1)) + hold (regardless of release) = NOP

I did a sketch for it this morning but had internet issues to prevent connection and post. It should say the same thing.

IMG_0989.png (45.25 KiB) Viewed 1878 times

5. I also like Dani's new proposal though. The similarity to the double shift to get g is appealing.

1. Pressing the function key [FN] once, normally or briefly triggers the function [FN]
2. One extended press of the function key [FN] triggers the function f[FN].
3. Pressing the function key [FN] twice triggers the function g[FN].

6. From a programming point of view H2X's is easier I think. I may try that in the week some time.

7. I also actually think Dani's (2) can at first co-exist with H2X (2). I could add a config flag if needed later. And Dani's (3) can also co-exist.

8. I also like the long press shift idea for HOME menu. That can also co-exist with the triple shift.


Jaco

[H2X]

Thank you for the think tank. I like the good discussion on this topic.

You're welcome, and thanks back to you for hosting it! I'm having fun!

5. I also like Dani's new proposal though. The similarity to the double shift to get g is appealing.

1. Pressing the function key [FN] once, normally or briefly triggers the function [FN]
2. One extended press of the function key [FN] triggers the function f[FN].
3. Pressing the function key [FN] twice triggers the function g[FN].

If I understand it correctly, the last option of pressing the function key [FN] twice can be done from a clean start, right?

[Jaymos]

Thank you for the think tank. I like the good discussion on this topic.

You're welcome, and thanks back to you for hosting it! I'm having fun!

5. I also like Dani's new proposal though. The similarity to the double shift to get g is appealing.

1. Pressing the function key [FN] once, normally or briefly triggers the function [FN]
2. One extended press of the function key [FN] triggers the function f[FN].
3. Pressing the function key [FN] twice triggers the function g[FN].

If I understand it correctly, the last option of pressing the function key [FN] twice can be done from a clean start, right?

That is how I understand it, i.e. that all items listed start from scratch.

[H2X]

...
If I understand it correctly, the last option of pressing the function key [FN] twice can be done from a clean start, right?

That is how I understand it, i.e. that all items listed start from scratch.

That sounds to me like a double press, where there is some maximum key up time between the two presses to identify them as double instead of two separate, single presses invoking FN two times in a row.

It might work as a charm, but might take some experimenting to find the right interval. I imagine that it might also be difficult to recover from an intended double press registering as separate single presses - or vice versa, if that should happen.

I do like Dani's suggestion of a NOP possibility for all keys. Have you given that some thought yet?

[Jaymos]

...
If I understand it correctly, the last option of pressing the function key [FN] twice can be done from a clean start, right?

That is how I understand it, i.e. that all items listed start from scratch.

That sounds to me like a double press, where there is some maximum key up time between the two presses to identify them as double instead of two separate, single presses invoking FN two times in a row.

It might work as a charm, but might take some experimenting to find the right interval. I imagine that it might also be difficult to recover from an intended double press registering as separate single presses - or vice versa, if that should happen.

That is exactly the issue. To make sure the system is practical. With the multiple taps to set f, g, and HOME, and cycle back, it makes no difference to the stack if you do occasionally get the wrong shift. With FN keys it is different as you say.

Personally, I will set up the H2X long press system first, as it is slightly easier to implement any way (it is a modification of the NOP system) and then I'll see about the double taps.

From my experience with setting up many timing issues on micro-controllers and recently the f/g shift cycle that you know of, programming timing issues to comply with human touch is often more involved than the basic timing diagram and requires experimental tuning of the boundary windows. I am pretty happy with the current version of the f/g cycle and the double tap CLR for DROP as it is now, and it is seldom that I miss a triple press for Home. But it does happen and that brings me to the point that if one does miss a triple press occasionally, the long press shift to call HOME, seems attractive.

I do like Dani's suggestion of a NOP possibility for all keys. Have you given that some thought yet?

I do not consider it as it will require a rewrite of some core WP43S parts and I do not want to deviate from the 43S structure too far on too many issues. I like to stay on the same maintenance path as the main project, where possible.

[rprosperi]

This discussion/meandering think-tank is indeed both interesting and productive.

I like both sets of ideas, obviously for differing reasons, but I'd caution against mixing them, as in my experience multiple simultaneous 'non-standard' sets of UI controls tends to confuse nearly all users. So I'd implement the 'long-hold' style, and in a parallel build the 'multi-click' style, and test drive both to see which feels better. But both at once will likely be confusing, to say nothing of difficult to code/test.

[keithdalby]

Has anyone mentioned pressing and holding a key for its second function? I use this ask the time on RealCalc (RPN mode, naturally) and I find it a real time saver. It'd love a hardware RPN calculator that does the same thing.