Closed chylex closed 2 years ago
I was hoping someone would stumble across that comment and implement the keyboard travel distance metric. Thanks for showing the visual diff, it's interesting to see how the manual ordering compares with your computed metric. As an added bonus, alternate layouts now have much better key prioritization. Awesome contribution!
Given your prolific contributions to AceJump over the last year, I've invited you to become a collaborator with push access. Should you wish to contribute this feature, we would be honored to have you make our 1000th commit!
Thanks, committed!
Finally decided to look into https://github.com/acejump/AceJump/blob/beb39c95c89092e7a1e79687ae01ca85ca1092fc/src/main/kotlin/org/acejump/input/KeyLayoutCache.kt#L12
I'm automatically generating a map of distances between each pair of keys based on the
KeyLayout.rows
. The algorithm assumes 1/4-key uniform stagger, with a heuristic that slightly increases cost of traveling across rows.There are some differences between the existing manual layout and the automatically generated one in QWERTY, but I think it overall looks pretty reasonable, maybe better in places:
Also, a look at the bottom of the list to find which combinations are considered the worst, I think the automatic generation is a bit better here in terms of symmetry and some of the combinations:
Non-QWERTY
Of course, the important part is that this should be much better for non-QWERTY layouts. For example, here is a comparison for COLEMAK:
Obviously, the first difference is that the automatically generated tag order prefers
td
(directly next to each other) overty
(6 keys apart). Overall, the old system kinda falls apart after it past the hardcodedKeyLayout.priority
order.I'll clean things up and commit, so you can take a look before a PR.