Extend FR and ES keyboards from the EN keyboard #4906
Conversation
Avoid duplication with the EN keyboard, as most is the same, and just tweak what has to be changed. Will allow staying in sync with the EN keyboard recent and futur developments of key popups.
|
It does make it harder to grasp what's going on. I thought you wanted to explicitly reuse the popup variables rather than the whole keyboard. I suppose it shouldn't matter too much. People who want to customize can just base it on the English one. Incidentally, shouldn't the French layout look more like this? I've never looked at the French keyboard before, but the description of AZERTY as QWERTY with four characters swapped struck me as slightly odd. ;-)
|
I don't think so. The stuff that changes and why is clearly stated in the comments.
I thought I would have to do that, and to update it each time you add a popup for a key.
Yes, |
(ok, bit of thinking happening right now) |
|
OK, it will now display as on your screenshot, with some possibly useful chars on the new key in the other modes (except for the russian-like modes where I had no inspiration). At least, what I thought would be tedious was actually easy with this extend/move/update way of patching the EN keyboard :) |
| } | ||
| for _, popup in ipairs(popups) do | ||
| if popup.east and popup.north then -- not all implemented yet |
There was a problem hiding this comment.
We can just add a couple of stubs instead? It's the other options that require thought but the basic òöóô-type ones should be fine.
There was a problem hiding this comment.
PS I'll do that now. Shouldn't take more than a few mins.
There was a problem hiding this comment.
Dunno (yet) what you mean by stub, but I'll see. But may be no need to add anything.
Anyway, I planned to remove that once you have implemented them for all.
So, no real need for anything more.
(And anyway, it's not even needed (and a bit wrong with my intent) : local toto = "zzz" ; toto.north returns nil, when I thought it would crash with "attempt to index a string" - but no - and if it's not a table it's a no-op)
There was a problem hiding this comment.
Alright, so let's take out the if condition and merge it. ;-)
There was a problem hiding this comment.
Alright. (so, UIO are done :)
There was a problem hiding this comment.
Just a stub; it'd require some more research to call it done. :-)
With the basic pattern of diacritics and special characters established by now, the basic diacritics + IPA don't need too much thought for an initial draft. Cf. koreader#4906 (comment)
With the basic pattern of diacritics and special characters established by now, the basic diacritics + IPA don't need too much thought for an initial draft. Cf. #4906 (comment)
…eader#4907) With the basic pattern of diacritics and special characters established by now, the basic diacritics + IPA don't need too much thought for an initial draft. Cf. koreader#4906 (comment)
Extend the FR and ES keyboards from the EN one, and just tweak what has to be changed. This will allow them to stay in sync with the EN keyboard's recent and futur developments of key popups. Also make the FR keyboard a bit more AZERTY.
Avoid duplication with the EN keyboard, as most is the same, and just tweak what has to be changed.
Will allow staying in sync with the EN keyboard recent and futur developments of key popups.
Pinging @pazos (#4244) for info, about the ES keyboard: i updated it because there were so little differences from the EN one - it should be the same as before, but it will be easier to tweak if you feel like removing "espacio" (like I did for the FR one) or re-order the key popups (like I did for the FR ones).
The other keyboard layouts are quite a bit more complicated, but some only have changes in the 3,4,5,6th layouts, so they could probably be tweaked with the same kind of remove/insert/replace tweaks if their users feel like enjoying the new popups.