Questions regarding the keyboard-config
Closed this issue · 8 comments
1. home_row_positions
home_row_positions:
Left:
Pinky: [114.5, 125.5]
Ring: [164.5, 125.5]
Middle: [214.5, 125.5]
Index: [264.5, 125.5]
Thumb: [351.5, 225.5]
Right:
Pinky: [564.5, 125.5]
Ring: [514.5, 125.5]
Middle: [464.5, 125.5]
Index: [414.5, 125.5]
Thumb: [351.5, 225.5]Why does it accept Positions and not MatrixPositions? The second options seems much more appropriate, since "Home Row" refers to certain physical keys.
2. positions
positions:
- [[ 25.5, 25.5], [ 75.5, 25.5], [125.5, 25.5], [175.5, 25.5], [225.5, 25.5], [275.5, 25.5], [325.5, 25.5], [375.5, 25.5], [425.5, 25.5], [475.5, 25.5], [525.5, 25.5], [575.5, 25.5], [625.5, 25.5], [701.5, 25.5]]
- [ [ 38.5, 75.5], [101.5, 75.5], [151.5, 75.5], [201.5, 75.5], [251.5, 75.5], [301.5, 75.5], [351.5, 75.5], [401.5, 75.5], [451.5, 75.5], [501.5, 75.5], [551.5, 75.5], [601.5, 75.5], [651.5, 75.5], [721, 75.5]]
- [ [ 45,125.5], [114.5,125.5], [164.5,125.5], [214.5,125.5], [264.5,125.5], [314.5,125.5], [364.5,125.5], [414.5,125.5], [464.5,125.5], [514.5,125.5], [564.5,125.5], [614.5,125.5], [664.5,125.5]]
- [[ 30.5, 175.5], [ 85.5,175.5], [135.5,175.5], [185.5,175.5], [235.5,175.5], [285.5,175.5], [335.5,175.5], [385.5,175.5], [435.5,175.5], [485.5,175.5], [535.5,175.5], [585.5,175.5], [681.5,175.5]]
- [ [ 38.5,225.5], [101.5,225.5], [164.5,225.5], [351.5,225.5], [538.5,225.5], [601.5,225.5], [651.5,225.5], [714.5,225.5]]Is there a reason why it doesn't start with a Y-value of 0 and instead uses "25.5"?
The home row positions are not MatrixPositions because it might well be that a particular keyboard geometry assumes your fingers hover between keys at rest, e.g. think about two thumb keys with no clear preference for one or the other.
They are currently only used for a metric calculating movement distance in line with Ian Douglas' KLANext evaluator (https://klanext.keyboard-design.com/#/main). So no additional properties than the positions are required.
Do you have a use case for which having home row positions as MatrixPositions is preferable? Would the program fail if there is no key with that MatrixPosition?
As for the starting value of 25.5, this is for compatibility with Ian Douglas' analyzer. The positions currently are only used for the KLA metrics, so I chose them in line with KLANext.
The home row positions are not MatrixPositions because it might well be that a particular keyboard geometry assumes your fingers hover between keys at rest, e.g. think about two thumb keys with no clear preference for one or the other.
That's an interesting point.
Do you have a use case for which having home row positions as MatrixPositions is preferable? Would the program fail if there is no key with that MatrixPosition?
My initial thought was that home row keys should always be ACTUAL keys. In that case, it would have been more intuitive and easier to use MatrixPositions.
However, if you're saying the intended resting positions can realistically be expected to be in-between keys, using Positions is perfectly valid.
In that case, I'd like to mention that different naming might be more intuitive. Something like finger_resting_positions would immediately convey what we actually mean and also indicate that the used positions may fall in-between physical rows.
Something intriguing is that with positions, unbalancing_positions, and the config we're currently talking about, there's some redundancy. I can see the possibility of automatically calculating unbalancing_positions from the other two definitions.
Calling them finger_resting_positions is a good idea.
Regarding the unbalancing values, I believe that this could not easily be derived from the resting positions.
Take, for instance, the index finger. The key on the upper row is only one row away and still, the key requires (at least for me) the hand to move. The distance for the middle finger is identical, but there, no hand movement is required.
Calling them
finger_resting_positionsis a good idea.
As long as it doesn't cause compatibility issues with KLA, I think it's the way to go.
Regarding the unbalancing values, ...
My thought is that when correctly assigning finger_resting_positions, you would actually do it like the following example.
finger_resting_positions:
Left:
Pinky: [114.5, 175.5]
Ring: [164.5, 125.5]
Middle: [214.5, 105.5]
Index: [264.5, 125.5]
Thumb: [351.5, 225.5]
...If we really assigned resting-positions according to the natural hand position, we could then simply subtract each positions from the finger_resting_positions of the finger that types that key to receive an unbalancing position.
However, there's also some flaws to this. The main ones I can see is that it may not capture finger-spreading and hand rotation as well.
At least for me, my finger resting positions are actually in a line (all on the same height on the middle row). The unbalancing values for pinky and index fingers are rather due to them being shorter fingers, I believe.
That may very well be. I understand the automatic generation of unbalancing_positions isn't bulletproof. Let's forget about that proposal. :)
At least for me, my finger resting positions are actually in a line (all on the same height on the middle row). The unbalancing values for pinky and index fingers are rather due to them being shorter fingers, I believe.
Just curious: Are you saying you're holding them there or that it's the natural way your hand is placed? For me, I obviously have to enter the "straight home row position" when typing, but if I just put my (curled) hand onto a table surface, the finger's don't automatically line up.
Regarding the naming-change, should I create a PR?
Not perfectly in line, no :)
But they would all still hover over their respective keys (pinky being on the edge of it, admittedly).
A PR would be awesome, thanks.