shortcut placing - are major shortcut symbols on left hand?.The source code for both apps are in the repo. The former performs well when starting from scratch while the latter is well-suited if starting from a given layout (both work in both contexts, though).įinally, there are two webapps available: One is a WASM-based online version of the evaluator/optimizer providing a significant subset of the functionalities (though no multi-threading) and the other features a database for comparing found layouts that one can publish to. The optimization (automatic search for good layouts) can be done using either a simulated annealing algorithm or a genetic algorithm. ![]() Many available corpora are German-based as this is my native language, there are several English ones as well, however. As the evaluation is performed only on the n-gram frequencies, the size of the corpus does not affect computation time a lot (I tested the 1M datasets from KLANext and they compute in a fraction of a second including n-gram processing). for home-row-mods), the number of layers and set of symbols that can be generated (on these layers) can be configured in YAML files.įor the n-gram data, I collected a small set of corpora from the University of Leipzig (Germany) and from logs of the #neo IRC channel, but it is also possible to provide your own text that will then automatically be processed into uni-, bi- and trigrams. the number of keys and their position split keyboards with thumb clusters), modifier positions (e.g. It is also really not hard to add your own metric to the mix as there is a clearly defined interface to be implemented.Īlso the keyboard itself (e.g. ![]() The various weights and factors can be configured in a corresponding YAML file. For instance, SFBs (here called "finger repeats") are not simply counted, but weighted by various factors such as which finger is affected, the number of rows to jump, or if it is a stretching or curling movement. The existing metrics have "comfortable typing" in mind and follow some design decisions that are certainly personal and thus also debatable. To my understanding, however, there are some aspects that are covered in more detail than what the "mainstream" analyzers out there do, see "What sets it apart?". Its general approach to evaluating keyboard layouts is not new and follows the ideas of other layout analyzers like KLANext (at least as far as I know): It evaluates a series of metrics that operate on frequencies of uni-, bi-, and trigrams (additionally, there are what I called "layout metrics" that only consider the layout itself without any extra data). ![]() The evaluator/optimizer is implemented in rust, which on the one hand allows for some good performance and on the other hand compiles to webassembly so that running it online in a browser is an option. Originally, I wanted to optimize Neo-based layouts (with six layers) on a "standard" ISO keyboard, in the end, the "base-layout" (which symbols reside in each layer) as well as the keyboard are configurable. Over time, the fun I had developing the software (and trying to squeeze out the last bit of performance) kept on increasing and with it, the project evolved into much more than was anticipated beforehand. The idea sprung from trying to improve an existing layout evaluator for layouts in the "Neo-universe" (German ergonomic layouts, see ) by Arnebab ( written in Python, but rather slow) and at the same time starting to learn rust. ![]() I want to introduce a pet project of mine that I have been working on in the last year - a keyboard layout evaluator/optimizer:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |