No ahah. I was talking about the âÂ, êÊ, îÎ and so on, as I didn’t see it on the @uzanto’s screenshots.^^
Your last proposition is the best that we can achieve for now in my opinion.
EDIT: actually, the çÇ is not useful anymore in the fifth panel in my opinion. But it’s also a thing of habits. Maybe another french speaker could tell us if it makes sense for him.
I edited it again [to the last version above] and removed çÇ from the eschar view because they were already used. Also, because I had miscalculated (one too many characters in that row), and replaced with " ’ ". It’s a double as well, but might speed up writing when you don’t have to search for it from another view… or would some other character be even more useful (this may go to the area of “over optimization” at this point - can be changed later depending on feedback)?
One of the things we will be missing very soon is some kind of “best practices”. ATM we can take a look at the other layouts to learn how to make a good layout, but as things get more fragmented (with more layouts), it’s getting harder to find the “best” way to create a layout and have a consistent UX over different layouts (of similar kind).
For the German layout, it was quite easy as it doesn’t need a lot of special characters. I just had to take an existing layout and modify it a little bit. But even in this simple case I had to decide if I wanted to keep the German umlauts in a special layer (with “äÄ” as the switch key) or put them on the main layout. I decided to keep them in a special layer to avoid cluttering the basic view and avoid shrinking the button size. But that was just my personal opinion! It’s probably neither good nor bad - just a thing of personal preference.
Some small points I noticed as I made the German layout (and that should be consistent over all layouts IMO):
Do we want the switch key between numbers and letters to be upper case letters “ABC” as in the original US layout or lower case letters “abc” as we have it in some layouts now?
The preferences key (globe symbol) should probably be consistent over layouts and use the “special” outline
The view/button named “eschars” comes from the Spanish layout. For German I renamed it to “dechars”, but maybe we want a more generic name there? What about “accchars” for accented characters?
Are there other things I missed?
My general understanding of the key color in the layouts is this: All keys that produce a normal character/letter output are “light grey” and other special keys as the “settings” key, “bachspace” key and keys that switch to another layers like “ABC”/“123” are “dark grey”. I hope that this inference I made is correct.
The only very different layout at the moment is the Japanese Kana layout. I tried to add some comments in the YAML file to document some of the special things done there - hope that helps a bit.
Excellent points. They may not seem relevant to individual user or at the moment but later one they might start to irk, so it’s good to get them settled now. I’m happy with your points being here and agree with them, but I think a copy should also be submitted to somewhere in git and/or dev mailing list, maybe(?).
(and btw. I thought “eschars” was from extra or especial characters… )
Good idea - but let’s wait a bit until we have some more comments in this thread and can make a list of initial “best practices”. @dcz: What do you think about a “best practice” document in the git repos?
Interesting… that’s an example of how different people interpret the same code in different ways… then I’ll take a note to correct this in the next MR for the German layout. Your interpretation seems reasonable
What I think would be even more useful than best practices is a basic introduction and format description. As I’m putting all my effort to pack new features in, and you guys have figured it out already, it would be extremely cool to have such a document.
If anyone is already working on best practices, tutorials or whatever, please make a MR in the keyboard repo. If we later decide to use the main docs, we can move the files there.
Gnome translations collectively increased +10% but not much happened to L5 apps last week. Participation is appreciated, I would imagine. Only a few words here and there, is all that’s needed at a time.
I did a quick check and a few cases, layouts need only tweaking of a few characters, after which they can be copied and renamed layouts for another language. Catalan, Danish, Esperanto, Basque and Czech, to name some. They still need native-level to verify that most used characters are in logical places or where they are commonly used on a layout.
It’s long overdue to write a comprehensive guide how to add a keyboard layout from start. But unfortunately, I don’t have much time left ATM. A lot of information can be found in this thread.
So at least I will try to start writing a short how-to here and edit this post as I find the time. Hope this helps a bit - comments and corrections welcome.
The keyboard layouts are located in the subdirectory data/keyboard/ in the .yaml files
Take a look and try to understand them
Fork your own copy of squeekboard
Best way would be to start with a fork of the squeekboard repository: Create a user account at https://source.puri.sm/, go the the squeekboard git repository, press “Fork” in the web interface. You can find further instructions here.
Clone your fork locally with git clone and use the uri of your forked repo there
You can either test it locally on your Linux system or use the QEMU Librem 5 image
To test squeekboard locally, you need phoc. Either compile that from the sources as well or use the CI repository ci.puri.sm for Debian based systems: deb [arch=amd64] http://ci.puri.sm/ scratch librem5
Squeekboard can be installed from there as a Debian package, too (that’s what I often do). But beware - there be dragons! You could bork your system with these packages and you should probably disable this repository again after installing what you need - these packages are not meant for production systems (or so I heard )
The correct name of the .yaml file can be found with the command gsettings get org.gnome.desktop.input-sources sources
The output should be something like this: [('xkb', 'us'), ('xkb', 'de')]
So f.ex. “de.yaml” would be the correct name for the German keyboard layout.
The translations for the keyboard layout names in the different languages can be found at data/langs/
Don’t forget to add your newly created layout or translation to src/resources.rs and the layout to tests/meson.build (that’s for me, because I always forget it)
Testing the layout
Copy your yaml file to ~/.local/share/squeekboard/keyboards/ for testing purposes. From there it should get picked up by squeekboard
To test the translations in data/langs/, you have to compile squeekboard
This is awesome. Do you mind if I take it and put into the official keyboard docs? (and possibly developer.puri.sm ?) If yes, then I’m going to bump providing good documentation a little on my list.
)
