Implement non-square keys

[Zwyx]

Implement non-square keys

by splitting key_size in key_height and key_width

---

I think having key height and key width allows more precision than a ratio setting. It also doesn't require to know the screen width and the number of keys in the keyboard.

Notes

• See discussion in Stretched display mode #640.
• Please forgive this unannounced PR, I wasn't expected to have something working so quickly... now that I have it, I share it, but I wouldn't mind at all if this isn't accepted.
• If you want to test it, you will have to clear your app data (not of your main keyboard, just the debug one). This is because the database schema has changed.

Left to be done, if we choose to go ahead with this proposal

• write a migration for the database,
• update all translations of key_size.

---

[Evengard]

I was mostly thinking towards the direction of making it one of the toggles parameters, which maxes out width but still can change the actual key height through the existing key size param.

That way backward compat would be preserved too, I think.

Good job though, that was quick!

[asdkant]

Since you're already working on this part of the code, can you add a slider for the horizontal position of the keyboard? (instead of the current left/center/right options available)

[Kommynct]

this would also technically solve #653

since you could submit multiple layout sizes, although having to hard code the different layout sizes yourself will be annoying.

[RainOrigami]

@Zwyx unfortunately your build has failed, but I'd really like to try this. could you fix the formatting so that the build succeeds and we can get the artifacts from it? idk how to build this myself.

[Zwyx]

It's done @RainOrigami, however I'm actually interested to know where you retrieve the artifacts?! I can't find them in Woodpecker but I'm not familiar with it.

[RainOrigami]

Hm yes you raise a fair point, I would have expected some to show up when the build task completed.

I guess I have to figure out how to build this 😵

edit: oh no this is way harder than I have anticipated, I have to like sign this file too and shit

edit2: ok thank you, I am now beyond happy and this makes it the perfect replacement for messagease!

@Zwyx to note, there are some errors still that prevent the assembleRelease build from gradle, but not the assembleDebug build. I suppose the debug build doesn't contain translations? Anyways, there are <string name="key_size">.*</string> in the strings.xml of the corresponding languages that now have been changed to key_height and key_width instead. I just removed these lines from the xml files to make the release build succeed.

Or I do not know how to properly build a release, anyways once confirmed that this PR doesn't break anything, pleasepleasepleaseplease @dessalines accept this PR <3

[dessalines]

Needs a migration.

[dessalines]

Don't change the names of existing columns, or you'll break installs.

You'll need to do a migration to add more.

[dessalines]

My main recommendation for this PR, is that height and weight should by default be tied together. Add a boolean setting (that doesn't actually link to anything in the DB), for something like "Use different height and width", which is shown either if they're different.

And then show both sliders. Otherwise, the first slider should change both the height and width as if they were the same.

[Zwyx]

Thank you @dessalines, happy to see that you approve the idea :-) The boolean setting is a great idea! I'll work on that.

For the names of the columns, I will keep key_size and add key_width.

[Zwyx]

I have implemented what we discussed:

• By default, nothing changes for the users:
  • we still have Key Size,
  • the new setting Use Non-Square Keys is unchecked.

• When checking Use Non-Square Keys:
  • Key Size becomes Key Height,
  • Key Width appears, and is set to the value of Key Height.

• Changing Key Width makes the keys become rectangular.

• Unchecking Use Non-Square Keys resets the keys to square.

I have tested that this works for both a fresh install, and an update (the DB migration works).

@RainOrigami, you can do Menu → Build → Build Bundle(s) / APK(s) → Build APK(s) to get a debug APK that you can install on your device, no need to sign anything 😉

[RainOrigami]

@RainOrigami, you can do Menu → Build → Build Bundle(s) / APK(s) → Build APK(s) to get a debug APK that you can install on your device, no need to sign anything 😉

Nah that'd probably require an IDE and like 60GB worth of SDKs and libraries. The docker approach worked for me, I did end up building the debug configuration instead of release, which signs the apk and lets me install it 👌 Good enough temporarily and seeing how you knocked this feature out of the park, I can probably expect this to be in the next release fingers crossed! Nice work!

[Zwyx]

Thanks!

Ah yes it does require all that. Could you share more details about how you did it with Docker?

[RainOrigami]

Ah yes it does require all that. Could you share more details about how you did it with Docker?

$ git clone https://github.com/Zwyx/thumb-key.git
$ cd thumb-key
$ git checkout non-square-keys
$ docker run --rm -v "$(pwd):/workspace" cimg/android:2023.09.1 /bin/bash -c "cd /workspace && sudo chown -R circleci:circleci . && ./gradlew assembleDebug"

Resulting APK is in app/build/outputs/apk/debug/app-debug.apk

[Zwyx]

Oh excellent! You took it from the Woodpecker file, makes complete sense. Love it. Thanks for that 👍

[dessalines]

This works well, but see if you can make key_width a nullable int column, as that makes more sense.

[dessalines]

You can tell that 0 is being used as a sub for null here, otherwise this could be as easy as

val legendWidth = settings?.keyWidth ?: legendHeight

[dessalines]

Based on some of the logic below, 0 is being used as a sub for null. Really this should be just

alter table AppSettings add column key_width Integer

which should make it of type Int?

[Zwyx]

Makes complete sense indeed, I'll do that. Sorry I'm new to Kotlin and my work is based on copy-paste of existing code 😬 Thanks for your patience 🙂

[dessalines]

No probs!

[Zwyx]

Ok @dessalines, it's done 🙂

I had two questions:

• Have you noticed that very the first time the app starts (after being installed), it does nothing else than a black screen? It doesn't matter much of course, it just has to be relaunched.
• Have you considered setting up GitHub sponsors? It would make it easy for GitHub users (including me 😁) to sponsor you.

[dessalines]

I haven't noticed the black screen, you'll have to open an issue for how to replicate it.

I don't use github sponsors, but have liberapay and patreon. Liberapay is much preferred since they're open source themselves, don't take a cut, and are funded by their own model.

[dessalines]

Works well, thx!

[dessalines]

Some things for future PRs:

• Make sure in either a commit message, or the pull request text, have the words fixes #ISSUE_NUM so that it will automatically close the relevant issue.
• Use mark as draft and ready for review when you're ready for me to take another look.

[Zwyx]

Thank you, donation set up on Liberapay 👍 Thanks for making Thumb-Key!

I take note of these two things for future PRs.

[dessalines]

No probs, thx for this!