I thought that I would share some notes garnered from recent experience working with Keyman Developer and 3 keyboards that together used over 230 layers (and 50 more I disguarded). These are some notes on what might make working with a large number of layers easier. I’ll enter some of these as feature requests in github, along with a few bugs that I’ll forgo describing here.
Working with many layers, I was wishing for a few more KMD buttons to help manage the layers. Such as:
Copy (Duplicate) a layer. Without a copy button, I would go into the code tab and carefully copy and paste a target JSON fragment.
“Next” and “Prev” buttons or arrows to navigate to the next or previous layer. The menu to select a layer is helpful, but you end up doing a lot of scrolling to get to an adjacent layer, it’s easy to mis-select and have to start over.
Reorder layers. An occasional need, copying and pasting JSON blocks is the alternative. It’s a lot of text to locate, then copy and paste without error.
An “Apply to all Layers” edit button or checkbox. When making a change to a key, like changing its type, or adding the “shift” modifier, etc, you will need to do this over and over, like 50+ times which is error-prone (a “Next” button would help here). So it would be helpful to make the change across all layers automatically for the same key ID.
In the Code panel, I ended up copying and pasting a lot of JSON, I’m grateful it is even possible. The feature that will collapse and expand a JSON object is very helpful here, you can copy a collapsed block and paste it where desired. I do wish that when pasted, it stayed collapsed. Instead, it will be expanded, then it can be difficult to relocate your starting point for the paste (feature request).
Other KMD enhancements (feature requests):
When clicking on a key, show in a status area what the x, y position is of that key. This helps with layout design.
When introducing a new T_ key, track the key in an index so it can be offered in auto-complete menus later.
In the web-based tester, show in a status area (maybe in the info area at the top) the name of the current layer. This helps you verify that you’ve switched layers as intended, and know which layer you are on.
I think it would be helpful to be able to add a “tag” for a key. The tag could then be used as an identifier for CSS styling later.
Layer Inheritence
Some thoughts for a future layer model. A layer inheritance approach would be something to consider. This would help mitigate the need to propagate a change across all layers. The idea here is that layers have an ID, a new layer could “inherit” another layer by its ID. From there, if a change is made to a row or key within the base layer, then copy of that row or key data with the changes appears in the record of the new layer.
Going further, a tablet layout could reference the phone layout, and extend as needed. A tablet layout could also reference phone layers as needed selectively.
IMHO, I think keyboards should be kept simple. No single keyboard can do everything in the world. Keyboards that try to do everything such as type all the languages in a country or continent are simply inefficient for typing any text of reasonable length. If the keyboard supports many languages, each language can have a separate keyboard. The Gboard in my device has only six “layers” for English language, and it does its job very well.
If a keyboard has 50 layers, it is very likely that only a quarter, or less, of the users will be able to use up to 5 layers. 230 layers is a huge number.
It’s just an opinion. Ignore if it doesn’t apply to what you’re doing.
You are certainly stretching Keyman’s design in ways we didn’t anticipate! There are certainly a number of ways we could improve the touch layout editor, particularly with grouped actions, and things like copying layers (although I think when you add a new layer it copies the layer you are on?). I think you do have a special use-case though so not sure there is significant value in optimizing the editor specifically for Massively Multi-Layer Keyboards (MMLK from here on in?).
Where there are improvements we can make to the editor that positively impact the experience for all users, certainly we will try and do that! I’ll take a note of your suggestions in a Keyman Developer feature request and we’ll look at what we can do with a future release
Ah, yes, sorry! I saw this and then forgot when I was writing my reply. I’ll let you write these up as feature requests on GitHub – if you can keep in mind the general use case as well as your specific stretching-the-limits case
Thanks @Marc , I’ll be filling out github issues over several days, a few at a time. I think you understood the MMLK use case from past discussions, I should have added some context to this post to clarify for most everyone else. The MMLK scenario arose out of bringing your solution for emulating dynamic keycap updates to full fruition:
I love that it can be done, with a bit of care, I’ll gradually apply the approach to my past keyboards.
I was thinking that you may find it worthwhile to generate the .keyman-touch-layout file using a script. While writing the initial script may be a bit of effort, it would make adjustments easy and would avoid the potential for inconsistencies to creep in.
Being JSON, writing the script in Javascript using something like Node would be the best bet – then you can just check the script in with the keyboard.
In this situation, you would use the touch layout editor only to verify the layout; if you found problems, you’d adjust the script and re-run it.
Of course, a more dynamic approach in Keyman would reduce the need for so many layers!
