What you are saying makes sense, and would not be hard to implement. However the trick is to keep the configuration simple for the user. It starts to feel clunky when you are having to select layout and language separately.
One idea might be to have an “override layout” selector which if unset (the default) leaves behavior as now. If it IS set, that layout always takes precedence, and only the language changes when selecting by the regular mechanism.
How does this sound? It would be preferrable not to even add this one additional selector, but I cannot think of any simpler way.Thomas Schewe supported this idea ·Thomas Schewe commented
I have the same Problem here. I write in German and English and I don't want to switch the layout, cause I slows me down.
It somehow works with the Apple virtual keyboards (I am now writing with the German layout (the one QWERTZ w/o äöü, and don't ask me again, why I want to use PadKeys). I don't switch the language and autocorrection still works for *both* languages.
I have no idea, how you can implement it in an elegant way.
Your proposal sounds somehow good, but how will the language-switching work? A second entry in the list of keyboard? Or will it be necessary to "slide" to the PadKey settings and change it there? This would be pita.
Thanks for your thoughts. I’m just wondering though, what would be the purpose of using PadKeys in this case? Why not just use Apple’s keyboard?Thomas Schewe commented
I don't need PadKeys for the äöü, cause one of the Apple Layouts includes them.
So the question reduces to "Why to use PadKey in general?"
I thought it would be clear: The keys to move the cursor. The permanent row with the numbers.Thomas Schewe shared this idea ·