-
Notifications
You must be signed in to change notification settings - Fork 239
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it easier to create variants #700
Conversation
THumbkey commenting is temporary
@dessalines I'd like some help with this one. It's working flawlessly once you've shifted and gone back, but the initial keyboard isn't showing the change. Any idea why? Is that just some cached state issue? Current code has a test set up on english thumb-key. Should have thorn symbols in the middle |
367bba8
to
7bea74b
Compare
Also added a function to auto-create shifted layers |
I'm sure it has to do with mutability, and how terribly its handled in kotlin / java. Make sure that you are never changing or modifying the original keyboard, but make |
|
||
// Merge swipes, with variant's swipes overriding source's swipes for the same SwipeDirection | ||
val newSwipes = | ||
source.swipes.orEmpty().toMutableMap().apply { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
apply
might be the issue here, I think it alters source data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I thought I was creating a mutable deep copy. I'll investigate, thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no dice so far with this route of investigation. converting to a map creates a copy, so the original isn't being modified at all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not looking like this was the issue. Probably need to figure out how to apply the debugger. Gonna be a wee while, I might not get time to work on this for a week or two
Thinking more about where this is heading.
|
i'm not going to touch settings, at least for a while, so once this is merged that might be someone else's job |
// Returns a variant of a layer created by replacing source keys and swipes | ||
// with any non-dummy equivalents in the variant. | ||
|
||
// Assuming both source and variant have the same structure (same number of rows and columns) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be prudent to have some check for source and variant actually having the same structure, although I'm not sure how to enforce that at compile time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the works
@BlueDrink9 I've been thinking that it may be a good idea to do some slight changes on the dataclass I'm not sure if another mechanism should be set for languages that are much different, if there's another slightly similar mechanic then the value could be an enum instead of a boolean flag (maybe make it an enum anyway since it's safer and more maintainable) |
i think i'm missing some pieces, could you describe the motivation in more detail? that function already calculates shifted layers |
I'm assuming that there are languages we'd want to have but don't have lower/upper case as we would think of it, or someone may want to make a keyboard that doesn't just change alphanumeric characters to upper case on the shifted keyboard, but we want to make life easier for the (I'm assuming majority) people who make keyboards with lower/upper case mechanics where the shifted layer is just main with upper case letters. Looking at EsMessagEase for example, declaration of the layout is: val KB_ES_MESSAGEASE: KeyboardDefinition =
KeyboardDefinition(
title = "Español MessagEase",
modes =
KeyboardDefinitionModes(
main = KB_ES_MESSAGEASE_MAIN,
shifted = KB_ES_MESSAGEASE_SHIFTED,
numeric = KB_ES_MESSAGEASE_NUMERIC,
),
) My thinking went along the lines of guardrails to ensure that we're doing things "the proper way" with any given keyboard. If the new convention is that Changing how edit: thinking a bit more, we could just add a replacement for |
oh yup, that's good thinking. Definitely out of scope of ths PR though |
I've also noticed that this whole big keyboard config file is really prone to bugs, and I have some WIP branch that would allow to create 3x3 keyItemC based on simple(human-readable) text config. Something like this val SOME_POLISH_TEXT_LAYOUT =
"""
+---+---+---+
| | Ń |Ł |
| A-|+N!|?I |
|¿ĄV|\L/|X=€|
+---+---+---+
|{Ó%|QUP|| }|
|(WK|COB|MR)|
|[Ć_|GDJ|@ ]|
+---+---+---+
|~ Y|"H'|F&x|
|<ZŹ|ŻET|ŚS>|
| Ę |,.:|; |
+---+---+---+
"""
.trimIndent()
.replace("¿", "\$") // \\\$ would brake ascii table formatting so some kind of replacement'¿' is used instead
val KB_PL_EXAMPLE = makeVariant(
SPECIAL_KEYITEMS_AND_SPACE_KB, // 4 x 4 with shifted mode, and whole right column and space bar
getKeyboardFromTextLayout(SOME_POLISH_TEXT_LAYOUT) // upper-left 3 x 3
)
I have a working example but still need to clean up some code 🧑🏭 I've noticed you're both worried about mutability - is there some evidence of it? Because I haven't noticed any side effects 🤷 |
I think my bug is caused by something other than mutibility. Fyi, dessalines has expressed elsewhere a strong opposition to text-based (or rather, non-typed) layout setup. |
Also, would this handle asymmetric/non grid layouts? |
At this moment, it only handles a 3x3 grid. I probably could extend it to any MxN grid of squares if needed, but I don't know if it's a good option because:
@dessalines Are there some specific reasons for this? I think it could really reduce the amount of code and work needed for new layouts, and also make them more bullet-proof. |
Yes that's correct, I'm not going to support a 2nd untyped keyboard definition. Every keyboard, and all its fields, must be compile-time checked. |
If this is being loaded/converted into the relevant KeyC etc objects, that'd still be compile-time checking they work, right? |
Most likely no. You can always go from typed to untyped, but not the other way around. |
I'm not really sure at which point my code would lost this "compile-time checking".. Finally I found some time to clean up my code so I've cherry-picked part of this PR and created #811 for further discussion. |
If you want to maintain a separate format, you'll have to do that in your own repo with your own script. I don't have time to do so. Can re-open if the OP would like to continue work on this. |
Should help a little to tame the ridiculous proliferation of variants, and reduce conflicts when people update them or fix bugs.