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.
Oops …by either the Terminal (stuff in parentheses) or can install from an application such as synaptic package manager.
Once this is done…
@uzanto’s keyboard layout is in squeekboard now! Thanks!
It’s going to take some additional MRs before it works and looks as intended (them bugs), but it’s there and not going anywhere.
1 Like
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.
1 Like
One idea I have is to make the eschars button work the same way the Shift_L button works:
action:
locking:
lock_view: "eschars"
unlock_view: "base"
This saves one click by not needing to press it again to go back to the base view.
1 Like
The fastest the better when typing, I didn’t understood perfectly how it’s works when I started with the keyboard really.
How can I update your changes in my fork trough the webapp? I can’t see the Spanish layout in it.
That’s totally expected, we didn’t write the documentation yet.
The file is here: https://source.puri.sm/Librem5/squeekboard/blob/master/data/keyboards/es.yaml
It will be picked up by the application after someone reviews and tests https://source.puri.sm/Librem5/squeekboard/merge_requests/188 and https://source.puri.sm/Librem5/squeekboard/merge_requests/186
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.
[atsol@thinkpad build]$ LC_ALL=C phoc -l 3 -E /home/atsol/tmp/build/src/squeekboard
(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]$
This looks fine. I missed one step from the instructions:
python3 tests/entry.py
This will start a program with an input field. Without an input field, the keyboard doesn’t have much to do.
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 谷歌拼音:
1 Like
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.
A proper solution will arrive at some point, but there’s still stuff missing. If you have comments, please leave them here: https://source.puri.sm/Librem5/squeekboard/issues/122
2 Likes
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
1 Like
dcz told me how to do that in this topic:
show_YOURCHARACTERSNAME:
action:
locking:
lock_view: "YOURCHARACTERSNAME"
unlock_view: "base"
outline: "altline"
label: "GREEKLABEL"
If you want, send me your code and I’ll have a look to it.
1 Like
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.
Thanks.
Is there extra whitespace before/after the Shift_L key in your view definition? Maybe a tab character that is converted to an extra number of spaces?
The problem is that the shift overlaps the edge of the keyboard rectangle. I don’t know what makes it extended this way, but the solution to that is to mess with the “bounds” in the top level of the layout until it works, or to make some keys narrower.
This is also a bug I want to take a closer look at next.
I was about to write the same as dcz, you are adding an extra button per row and increasing the size of all the buttons, just needs adjustments to make everything fit inside the keyboard bounding.
Take the default measures and then reduce until its fine (just the width value)