Squeekboard release 1.21.0

Hardware Librem 5
1

Hello everyone,

after a longer hiatus, Squeekboard gathers some improvements for a new release. Apart from some sizing fixes, there are new translations, a new Hungarian layout, and polytonic Greek uses a font that makes it readable.
Thanks to all the contributors!

8 Likes
2

Am I interpreting the closed list right, there is support for long press character selection now?

3

You’re not interpreting something right :slight_smile:

1 Like
4

What’s going on with that then - any hope for it?

5

Patches welcome, it’s not the highest priority task right now. I’m personally more focused on cameras than input methods at the moment.

4 Likes
6

cant wait to try it. the recalculation of keyboard size/height, and not redrawing the entire keyboard for each keypress would be my favorite next items :slight_smile: - but good to hear you are working on camera related improvements.

7

I’m not sure what recalculation you mean, but if you mean the bug that occured when rotating, that’s fixed.
If you mean support for more devices, you could help out here, e.g. by writing tests: https://gitlab.gnome.org/World/Phosh/squeekboard/-/merge_requests/588#note_1674676

Why is redraw important? I’ve not seen any indication that there’s anything wrong with redrawing so far.

8

I’m checking for this upgrade each day since you made the announcement.
Many updates are being deployed, but the new squeekboard is not among them.
Can you give us a hint when it will be available?

1 Like
9

Um, soon I guess. Watch the “byzantium” line: https://software.pureos.net/search_pkg?term=squeekboard

2 Likes
10

Squeekboard update has been deployed a few days ago already and it’s on track to migrate to byzantium: https://master.pureos.net/migrations/excuse/b4d1f349-8221-4ab0-905b-026bd0106057

1 Like
11
  1. https://gitlab.gnome.org/World/Phosh/squeekboard/-/issues/338 and similar items that address maximizing usable keyboard height, width proportionally to available screen height and width that change through display scaling, screen rotation, or with using different phones.
  2. The redrawing is relevant on mobile devices and those with limited resources, it will use up less CPU when not redrawing everything (i have found squeekboard uses ~60% CPU in htop when just keeping pushing OSK keys) and saves battery (and maybe make it more responsive too).

Below shows where i keep selecting the cursor buttons up and left, the faster you push the more CPU.

squeekboard2
squeekboard2720Ă—1440 93.4 KB

12

The image shows about 0% CPU usage btw. I have a hunch you meant to post a video.

13

Blue highlighted line shows 45%.

1 Like
14

it varies but i used to be faster and get it up to 60%, not sure what that would translate to in real mW battery burn but someone would have to hook up a current meter to measure if this is just an artifact of htop (it is missing a value for power consumption), if those redrawing CPU spikes are just microseconds they may not add up to much, but if redrawing takes a lot more time they could

15

This needs some profiling before settling on a solution. If you’re willing to do that, it would help narrow down the issue before tackling it.

I can’t justify working on it myself unless it’s deonstrated to impact real use cases.

16

understood ill see if i can profile this issue and play around a bit more with measuring watt usage of the process