I would like to make an Ancient Greek layout for squeekboard but I have a big problem: the huge number of diacritics combinations: there are 2 breathings, 3 accents and the iota subscript which combine themselves for 7 vowels.
I am making a layout by noting all possible combinations in different views but it’s really a lot and it’s not practical at all. On my PC I use this layout (in french) : https://debian-facile.org/doc:environnements:x11:disposition-grecque-polytonique it has a very interesting system of composition of the diacritical letters: there are keys which encode the diacritical sign (breathing, accent or iota subscript), this one is then recorded in memory and comes out on the vowel which is then typed.
I would like a similar system for squeekboard by placing a line at the top (similar to the terminal layout one with Ctrl, Alt…) that allows to encode the diacritics that will then appear on the vowel typed after.
This system is called dead keys and I use it all the time on my laptop for Dutch input (keyboard layout “US International with dead keys” – this is basically the standard input method for Dutch users). I don’t think Squeekboard supports that, but it would be really interesting to have on a mobile keyboard.
Yes, I would also like to have an international English keyboard with dead keys. I regularly have to type characters like äñé¿¡ even when most of the message is in English.
Dead keys can be implemented using separate views. Make the dead key switch to a view that contains the modified letters, and you’re done. The Polish layout is something like that.
You can also directly input Unicode characters, but then you need to enter the unmodified letter first, and then a modifier accent. But messing up is easier, so I don’t recommend.
Heh, but ancient Greek is brutal, for example it has:
ᾊ - U+1F8A GREEK CAPITAL LETTER ALPHA WITH PSILI AND VARIA AND PROSGEGRAMMENI,
This would require going through 3 intermediate views. Just by naively going through unicode table of greek diacritics, gave me a total of 33 views, and 9 (sic!) dead keys to go from “unadorned lowercase letters” view.
Things might get cramped.
Edit: not saying this is impossible, but prepare for quite an undertaking.
That’s a lot of views, but they are mostly copy-pasteable (at least for the unaffected characters). I don’t rule out some implementation of dead keys, but I’m going to be more positive towards it if it can’t be implemented using the current system or if it could only with serious shortcomings.
Even better, designing a way to add them without making everything a special-cased mess would make me happy. I failed so far.
I do not know why I missed this thread… anyway, @Inuit did you found a way to solve this problem? It would be great if the keyboard supported multiple dead keys as the Xserver does. But it does not. It would greatly simplify things. I created the Greek (monotonic keyboard) using the views and the experience with this is not at all great to my opinion.
I do not understand (@dcz) why L5 had to follow the Android+iOS method. This method is clearly inferior to dead keys. Even the long presses that they support is clearly inferior to dead keys. Sometimes I get the feeling people want to re-invent the wheel just to do things differently. They get bored with correct solutions… I am not saying this for squeekboard but for Android+iOS which kind-of served (to my eyes) as a prototype.
In any case, if we do not have multiple dead keys (not even one) then the only solution is “views”. If there is not progress with this I may be able to help.
However, let me warn: in SMS the recipient (say with Android) may not be able to see polytonic due to poor fonts. But I understand that this is important to support on L5, for example if a teacher wants to communicate with a student through matrix.
There maybe more problems with the implementation and maybe @dcz can give a hint. To make this work we need to be able to choose the font for the key labels. Because we need to have a font with small xheight as the breathing marks need serious space to be visible. Is this supported (the choice of the labels’ font)?
By the way, Control and Shift are not dead keys. A key is “dead” if you hit it, you release it(!), and the system waits for the next key to react. The contol and shift are kept depressed. They are not dead.
Android and iOS were not an inspiration simply because when I designed the system. I had very limited experience with those.
Thanks. I have never used dead keys, so the explanation was needed. Now, how it that different from the latching keys? Is it similar to how the Polish layout works?
Does the dead keys work like spanish accented keys? You press the accent and then the letter that you want accented? ’ and e will output é (not exactly because ’ is an apostrophe on the keyboard that I’m using right now but it works for the example)
If I understand correctly the term “latching”, they are not. I guess that latching is something like Caps Lock. Right? Such a key essentially is equivalent to your “views”. It changes the whole table.
A dead key is a “waiting” key. Waiting for the next stroke. The next stroke can be a letter or another dead key in which case the system still waits for the 3rd stroke. The Linux keyboard for ancient Greek uses a maximum of 3 dead keys. The Xserver has unlimited dead-key-capabilities. Modern Greek uses 1 dead key to enter its accents.
MS-Windows has support only for 1 dead-key. This is why even modern Greek is a pain on MS-Windows: We need to insert iota (the equivalent of i) with acute and dieresis (~umlaut). On Linux with the Greek keyboard enabled you press the key marked ; then : and finally the letter iota. That makes 2 dead-keys. On Windows this is impossible and they have weird combinations Alt+shift+blahblah to do it.
Back to Linux: on Ancient Greek vowels (and one consonant) we have maximum 3 breathing accents. So we need 3 dead keys. Desktop Linux implements this properly. To get the letter ᾆ we press the keyboard-printed-keys with : then [ then ] and finally alpha.
This simplifies a lot the typing. Without dead keys, using only “views” we could have a “view” with all the accent combinations and each accent should lead to another “view” with the vowels and the accent combination pressed at the first level. That will work I think and we could have this approach, this is why I offered to help if @Inuit has not done this already. The shift must lead to more views for the capitals. And all this is a lot of views. But we can try it.
No. Well, I only saw one keyboard that had a latching Caps Lock, but by now it’d be >40 years old. The key would physically pop out once you pressed a letter.
I checked it. The “Polish” (not other variants). It does not help in any way. The number of letters that get modified pressing the key with the modifiers is very limited. For Ancient Greek we talk about 247 combinations not for the 5-6 combinations of Polish. Since @Inuit did not answer I will start creating such a keyboard using views unless you have another/better idea.
in the yaml file of keyboards? I see in my gr file I had
outline: “altline”
and in other places
outline: “wide”
I forgot what are these doing.
Polytonic Greek is very close to be completed. Unfortunately there will be a lot free space in the views because we must provide people an easy way to find their way in all these accents. By mixing views just to fill them up we will end up with a very difficult to use situation.
OK, thanks. I have a first version for polytonic but something is wrong and can not find what. L5 refuses to load this yaml and loads the default for Greek although I have placed the file as “gr.yaml” in /home/purism/.local/share/squeekboard/keyboards/
How can I debug this? I wonder if squeekboard can load such a complicate file… Would you take a look? You are experienced and you may immediately spot the problem so I can fix it.
Can it also fail if the font cannot provide all of the needed characters?
Use the squeekboard-test-layout tool, it should be in the -devel package. Alternatively, squeekboard emits logs to stdout whenever it encouners problems. I believe those are somewher behind journalct.
I might have designed the format, but I’m not experienced in writing it
