5... 4... 3... 2... 1...

It's already late-January!

I've been having way too much fun programming lately, so I guess strap yourselves in, geminauts, for the greatest ride since Big Thunder Mountain!

Virtual Keyboard

The big news from wvkbd-land was a new release! Version 0.7 includes my swipe-output feature (`-O` flag). If you haven't read up on this, it basically just outputs the keys your finger slid over to standard output.

My only real complaint about wvkbd is with the default layouts and the complexity of configuration. (Like many suckless projects, it needs to be recompiled for major configuration changes.) The design of this feature means if something better comes along, we can easily drop it in without abandoning the rest of the pipeline.

swipeGuess

Over the last month I experimented heavily on swipeGuess, trying to improve both speed and accuracy. I made great gains in speed by rewriting in C; apparently grep's overhead for long expressions makes it much slower than a specialized pre-compiled implementation.

Worst case, the new version is only 7x faster. Best case, ~300x faster.

Because this is ten times better, I plan on discontinuing the shell version in the next release. The next area for performance gains might be rewriting completelyTypeWord as suggested in the previous post.

On the accuracy front, I experimented with using an sqlite backend, and improving the scoring function. With the user's keyboard-layout in hand, we can assign an accurate 'minimum swipe length' to each word. At run-time, we take the length of the swipe and say "WHERE score <= $swipeLen AND score > $((($swipeLen * 9 / 10) - 3))" to allow for some degree of imperfection.

This may be some day implemented into the C version, but it's not the perfect cure for accuracy, it only reduces the posible choices.

N-grams won't be the silver-bullet either: Often the same swipe could mean multiple words, even in the same context. (e.g. "I want *three* donuts" vs "I want *the* donuts"). For this, another tool can be used.

suggPicker

When I first got swipe-typing to work, I let my dad try it out.

> It got about 20% of the words right.

Knowing its limitations, I used it considerably differently than him. When something would go wrong, I'd delete it and type manually. Maybe too much dogfooding was blinding me to more conventional solutions? Eh, I won't tell anyone to use an iPhone.

suggPicker is a new program, developed off of wvkbd, which can be used much like bemenu: it takes stdin of choices, and outputs the choice. As a user interface, it's persistent, floating above the keyboard, and can change options in real-time, taking tab-separated input. I'm actually using it to type most of the words in this post.

Here's a shot of this post being written.

Currently, the pipeline looks like this:

In sitting between the existing pipeline, it slows down composition, but gives a chance for higher accuracy. I've switched to a longer word-list and not even noticed a difference in accuracy.

It could be used in other ways too. by taking input from a named pipe, we could instead

Use it to change already-typed words.

Use it to complete compound words, or predict the next word.

Use it as a generic toolbar for other apps.

Some combination of all of these ideas.

I'm sure you can see the possibilities, none of which require learning a new API or using a programming language that you hate. Building in this ecosystem is fun!

SXMO

SXMO got a new 1.7 release early this month, and they published the shortlog of committers. I guess I'm one of the top 7 contributors (by commits to sxmo-utils) for that release. Amazing what one can do with unlimited free time!

Stuff still gets frequently broken by the ever-changing code-base, but for the most part, it's getting better and better.

> The next release will be painfull for users

I'm currently working on support for system-installed appscripts, and sometimes some more boring stability things. Fish shell support hit a bump, and now I think building a 'friendly, interactive POSIX shell' would be better for all.

Mobile Linux Priorities

I worked on zachme-prototype, a proof of concept for acme-like plumbing on a touchscreen device. While it works for gemini-browsing, email-reading, and as a command prompt replacement, it's not very usable or friendly.

Maybe a suggPicker menu-like setup (similar to mil's fbp project) would be a good way to go, or maybe our hope is in the app-ecosystem getting better.

I'm probably gonna work on a low-priority project to scratch a personal itch, while ignoring the larger things.

I set up alpine linux (in sys mode) on a spare raspberry pi. It was kind of a pain... Alpine on Linode was way easier. The first snag was WiFi related: getting internet connected and the DNS server configured. Someone on IRC suggested one of the setup- scripts was broken (and that that was known), so I ended up learning more than I expected.

I want to use that box as a specialized web search server (with a gemini-frontend). Since I want to search gemini documents, I wrote some functionality for gmnisrv to proxy https content. After I got it working, I discovered by use of other client software that the SNI and cert should be using the *proxy-server's* domain (not the domains of the sites being proxied). That was kind of an 'oh duh' moment, but I didn't find any documentation about that.

Maybe I'll pick that project back up another day.

au revoire

Well, there's always more incomplete and experimental projects I could write about, but this is already my longest post here.

Comment publically on this post

or

Write to me on XMPP?