Thought on layouts defined as data

[asdkant]

One idea I've been bouncing around in my head is to define layouts in two parts:

1. The actual visual layout of buttons, each button having an ID
2. A dictionary of ID - behavior

If we have a few "standard" layouts, we can just direct people to use those instead of rebuilding the wheel for each layout.

There's also the right/left hand thing, and showing alphabetic and number keyboards at the same time or not, so we probably want the regular use case to be "use the standard behavior and here's the 3x3 grids for alphabetic and number keyboards"

The data structure for each key could be, again, a dictionary with touch actions as keys (tap, simple swipe, swipe-and-back, etc.)

This could be serialized in something like JSON, and if we define a schema that can take care of a lot of headaches before they happen.

if we define a way to "patch" layout definitions, we can let the user override a built-in layout without having to fully rewrite it (but better provide a way to import/export the current state of customization, just in case)

[asdkant]

One interesting thing I saw in thumb-key (haven't checked if it's present here) is that there's a function to get the currency symbol of the user's locale. That could be a config, and if we have alt symbols (the "C" in a box in MessagEase) we can have the other currency symbols as alts of that one

[nightkr]

This is pretty much how it works already, minus the JSON representation. "Controls" (the middle keys), numbers, symbols, and the language are all defined separately, and composed together depending on the user's selected configuration.

All key types are defined separately (Actions), and key layouts are defined as references to these.

[nightkr]

As for JSON support, I don't think JSON and Kotlin provide a meaningfully different experience as long as you still have to recompile the app to update them. The real value there (IMO) would come from implementing an in-app layout editor.

[asdkant]

I'd still try to define layouts as data and have a rudimentary system where the user can paste their definition in a text box. Not the most usable thing, but it'd get us halfway there and I'd be happy with that as an earlier solution (with the promise of better UX in the future).

[MisterE123]

Would it be possible to abuse a git repository for a collection of community-created downloadable layouts?
People could submit layouts as PRs, and the keyboard could search the repository for all available layouts, and download the raw configuration file for ones that the user wishes to install.

[nightkr]

I'd rather not add the network permission, so at that point it's mostly a matter of "layouts get pulled in during build", which is roughly where we're at already.

[MisterE123]

Ok, another idea then: put the complete layout settings definition into a URI... And then you can have a "share layout" feature without a network permission.

Users can click the share layout button, which copies the URI with their layout settings to their clipboard (or to social apps, its a generic share feature)

Others can click the URI which opens flickboard, reads the data, lets the user preview the layout, and asks if they want to apply it.

[asdkant]

This one sounds promising

[MisterE123]

themes could be shared this way too.