I think if you can’t test it, then it’s too early to submit the layout; others won’t be able to use it either. Where did you get stuck? Did you try running the testing instructions from the HACKING.md file?
If you did, then you can place the keyboard in the directory ~/.local/share/squeekboard/keyboards/, this will override the provided one (there isn’t one yet). Then use the settings app to select Greek as your system layout and confirm by:
gsettings get org.gnome.desktop.input-sources sources
gsettings get org.gnome.desktop.input-sources current
After you do that, you’ll get a good feel of whether the 11th button is placed correctly.
Oh, and the application will print things on the console if anything’s wrong. It will try not to crash even if something goes wrong. No one wants the input method to crash.
When it comes to an embedded US view, I’d rather not accept this upstream, especially as I’m working on the switcher right now. You’re free to have it as an override on your own system.
If you use this method, all you need is phoc, and it will turn into a window on your desktop. But there are probably problems with that, so unless you wish to help me better document the testing procedure, it’s better to use the emulator from the page you linked.
As you will be on a Debian Linux in all likelihood with PureOS or most others applicable (Debian OS, Ubuntu Touch, 4QOS, etc. simply install gnome character by either the Terminal (apt-update first, then apt-install gnome_charachters, etc.)
Once this is done you can use the app menu looking for ‘characters’.
This may not work for a keyboard of phone directly, but using Libre Office you can make and cut and paste from a saved list (smart list) of items to the needed applications, perhaps assigning some to a saved shortcut that can be pasted rather than doing this each time from the smart list.
The ‘problem’ here it’s about the virtual keyboard squeekboard and the use of ‘non common’ characters, like the ones we’ve got in French, German, Russian, Greek, Spanish… and it’s easy to fix just adding a new keyboard layout thanks to Purism team.
@dcz That’s nice, I hope we can add the long press support eventually because it will make it easier to type for us (non english speakers), but by the time being it’s functional like that, obviously needs some improvement, I’ll try to help all I can with this.
Yes I know, but if I want to edit something else in that file is asking to make another fork to do it and I’ve got already one done, I want to edit it in that one and then send the merge request to the main one.
It’s the first time that I use gitlab to send merge requests.
Gitlab’s patches procedure is based on merge requests. The preferred, simplest way is to make a fork (you did it already), and every time you want to make a change, go to the upstream repository ( https://source.puri.sm/Librem5/squeekboard in this case), and copy the branch you’re interested in into a new branch in your fork. I believe this is what happens when you click Edit. This is fine, every merge request should come from a new branch.
Yes. I had realized. The final modified squeekboard could be quite useful, though only applicable for Spanish and might be workable with many gyrations of activity.
I was suggesting a simple bypass using a facility already built into Linux with no Spanish limitation. Much less elegant, it may be simpler to implement for a good many. Making some base of a list of commonly used terms to be plugged in as needed may be worthwhile for those using a language only in a limited sense (citation, limited communications, etc.). Squeekboard use is laudable for those who are primarily Spanish. Librem 15 has various keyboards for its Laptop (https://www.crowdsupply.com/purism/librem-laptop/international-keyboards) and I am sure that they can transfer the same utilized code to formulating the Librem 5 keyboard with some similar code implementation if there is a need to have the phone function primarily in some alternate language for which they have already created the modification.
I tried first your method because is looks simpler than the emulator. But all I get is a black wlroots window. Maybe you can understand what is going wrong with the following log lines. I am on ArchLinux. If complains about X0, then it complains about non-existent undefined.yaml BUT then it loads us.yaml. But nothing appears on the black wlroots window.
(process:11326): phoc-wlroots-CRITICAL **: 10:33:54.803: [xwayland/sockets.c:63] Failed to bind socket @/tmp/.X11-unix/X0: Address already in use
Failed to load layout from Path: “/home/atsol/.local/share/squeekboard/keyboards/undefined.yaml”: Bad data: IO: No such file or directory (os error 2), using fallback
Key preferences has no keysyms
Loaded layout from Path: “/home/atsol/.local/share/squeekboard/keyboards/us.yaml”
libEGL warning: FIXME: egl/x11 doesn’t support front buffer rendering.
^C
[atsol@thinkpad build]$
Dorota, can you give me a hint how I could implement Chinese character support.
E.g. when typing zhidao or zd it should show following character 知道. Hitting space inputs the first highlighted character e.g 谷歌拼音:
Sorry, that’s not possible in squeekboard yet, the way you describe. You could perhaps hack up something using views to a similar effect, but in general, it’s only possible to enter Unicode characters (and soon strings) at the moment.
The Greek language support is almost there. Everything works after a problem with tabs and spaces. There is one remaining issue and a question about properly supporting accents.
bug: The Shift_L key appears with a very long space on the left. But I do not see anything wrong in my coding. I have uploaded my new el.yaml to the link I gave you with a personal message.
feature: It would be nice for the key that switches to the accent view to work the same way as the Shift_L works. That is, you press the accent key, you are presented with the accented letters, you choose one of them, and the keyboard should automatically switch back to the base view. How do you do this with the Shift_L ? Is it hardcoded? I do not see anything special in us.yaml
Ah! I missed it. OK, OK, I fixed it. The locking works. Final bug is why my Shift_L button appears so long as the above picture. If you can take a look I will send you a link with a personal message.
