Squeekboard 1.14.0 released

I’m not sure but I think when @dcz writes that the new version is “released” that means the source code for the new version is officially available at https://source.puri.sm/Librem5/squeekboard but then there is a delay of a maybe two or three days (?) until it reaches the amber (and/or byzantium) repos.

Not sure exactly what is happening during those few days that it seems to take, I guess some automated building and testing is going on but I don’t really know. If anyone knows then please explain, I would like to understand more about how the release process works and why it is setup like that.

1 Like

I’m not sure exactly the reasoning behind the delay, but I think it’s a period for testers to raise any red flags before it’s pushed out to everyone.

My observation was more in response to

a mistake prevented the two previous versions from reaching Amber

pointing out that I can’t yet confirm that this version has reached Amber.

I may have jumped the gun by a day or so, particularly taking into account time zones.

I’ve got 1.13.0-1 from the normal repositories feeding Mobian/Phosh on Pinephone.

1 Like

Now it landed in byzantium:

purism@pureos:~$ apt list --upgradable
Listing... Done
squeekboard/byzantium 1.14.0-1pureos1 arm64 [upgradable from: 1.13.0-1pureos1]

But looks like it’s still on 1.11.1 in amber, according to this check:

$ wget http://repo.pureos.net/pureos/dists/amber-phone/main/source/Sources.xz
$ unxz -f Sources.xz
$ grep -A1 "Binary: squeekboard" Sources
Binary: squeekboard, squeekboard-devel
Version: 1.11.1

Seems to be.

dpkg-query --list | grep squeek
ii squeekboard 1.11.1 arm64 On-screen keyboard for Wayland

(and I have applied all available amber updates).

It’s been stuck again, but eventually someone pushed it manually and it’s coming: https://lists.puri.sm/pipermail/pureos-changes/2021-June/001278.html

1 Like

…and it’s going to migrate from staging to production in a few days, which can be tracked at https://master.pureos.net/migrations/excuse/dab5e074-6445-4d07-b0b2-34be84b814e2

1 Like

Got it this morning… Love the caps-lock! Thanks, @dcz!

3 Likes

:+1:

(came through for me too)

This will be a godsend when entering acronyms. It is possible though that some of my posts suffer from EAD (excessive acronym density).

Also can be useful when entering long random passwords that happen to have consecutive uppercase letters.

1 Like

Plus, now we can SCREAM at the internet. :face_with_symbols_over_mouth:
(Kidding. Not my style.)

2 Likes

http://www.bash.org/?835030

4 Likes

Just an idea for now. I’ll try to learn more (when I have time), if it’s possible and how to do it.

I’m using the command line frequently, and the terminal view lacks some important keys for that, like Tab, ‘-’, ‘.’, or ‘/’. You have to do a lot of view switches to get those.

So I’m thinking to replace the thin arrows keys, and also the current Shift, like this:

  • make the current Shift into a Tab key
  • change the current thin keys row (Ctrl, Alt, Up, Down, Left, Right) to be: Ctrl, Alt, ‘-’, ‘.’, ‘/’, Shift (edited: the order of ‘.’)

Also I would like for the Ctrl and Alt keys not to stay sticky after I’m pressing a “normal” key and finishing the combination.

2 Likes

I’ve noticed some of the same issues. I have also pined for a more readily accessible | key.

However I use Up Arrow a heap, so I wouldn’t want to sacrifice that (or, to a lesser extent, the other arrow keys).

I guess I would make two comments:

  • no one keyboard layout will suit everyone
  • it is an open platform, so if you need a different keyboard, you can make one.

Like you though, I have no idea how to do that, how easy or difficult it would be, whether there is any documentation to help with that.

I think the terminal emulator should come up by default with a keyboard that is optimised for shell use (rather than a more generic one for use with GUI applications).

:+1:

I don’t quite understand the logic of Shift not being able to be sticky (but now at least it does have the sticky version i.e. Caps Lock) and Ctrl being sticky. I can’t quite see the use of having Ctrl sticky i.e. when you would key lots of Ctrl characters in a row. Maybe an editor where most things are done with Ctrl characters. It usually just catches me out typing rubbish because I left Ctrl on.

In the meantime I offer three workarounds, all of which work, if you have a lot of typing to do:

  • attach a USB keyboard
  • pair a Bluetooth keyboard
  • SSH in from another computer that has a more comprehensive keyboard

The third option has limitations due to the process context e.g. GUI applications probably won’t work (and I am also SSHing in as a user other than purism so settings don’t really work either).

Yes, that’s useful too. But Ctrl-P does the same think in the bash shell, so it might be a good compromise (if Ctrl doesn’t stay sticky!).

… but that’s exactly when you would want it to be sticky. :wink:

If you need to press Up more than one time, then I think it’s ok to switch views. You can also use Ctrl-R to search back in the history for previous commands and avoid repeating pressing Up.

I took pains to make it more easy than not: https://developer.puri.sm/projects/squeekboard/tutorial.html

Squeekboard’s not designed to be a keyboard, and does not aim to be a good one, so this feature has been neglected. Patches welcome.

3 Likes

I found it to be very easy to understand and modify the yaml files. I was able to do what I wanted and then change it again by moving the keys around so it to feel better. I see that I still want to do other changes. When I have something stable I think I’ll write a post about my new layout.

1 Like

I looked at it briefly yesterday. The first thing that I found is that I did not know YAML. So I went off to read about YAML. At a superficial level it looks simple, and mostly comprehensible without more documentation. I dare say I could change the label on a button or the size of a button etc. Making Ctrl non-sticky looked as if it might require looking at the code too.