@badrihippo Nice. Note that plugging in swipeGuess is the simplest approach. https://git.sr.ht/~earboxer/SwipeBehaviors has more elaborate setup. Nice thing is that p-o-s doesn't need to be changed, just the pipe configuration needs to be adjusted.

@agx right, thanks for the tip! Maybe I should make it into a mini shell script for easier editing (otherwise looks like I have to restart the shell each time? Or can I just restart the keyboard somehow?)

@agx initial feedback with the simple setup: I tried with a re-sorted version of the `wbritish` dict (Debian repo). Unfortunately the key-drag is a bit *too* sensitive (either that, or swipeGuess is not skipping enough letters in its computation). Meaning that I get some random long word suggestions, but it's hard to type "hey" 😕

On the positive side, if I disable `key-drag` and type the *ordinary* way, swipeGuess is giving better suggestions than I've seen anywhere else. The fuzziness helps 😉

@agx will report back after more experimentation

@badrihippo @agx
I usually get 'hey' for hey swipes, but sometimes hwy/hgwy. Enable multiple suggestions, and maybe cull some words from your list.

gsettings set sm.puri.phosh.osk.Completers.Pipe command 'sh -c "swipeGuess /path/to/words-qwerty-en_gb 5 | tr \"\t\" \"\n\""'

@badrihippo @agx I've been mulling over an idea in my head for better accuracy: run swipeGuess multiple times with various letter hitbox sizes (matches from the run with the smallest hitbox are preferred). Would require deeper integration with the host keyboard than we currently have.

@badrihippo @agx But as far as I know, the android open-source keyboards with swiping either don't work, or require a proprietary binary dependency, so I'm very happy we at least have something that makes typing more convenient. The proprietary ones lean (sometimes too heavily) on context for prediction, which at this state we haven't factored into the selection.

@zachdecook yep, me too; I didn't know till a few days ago that it existed and I'm delighted to hear it does! Also the modularity of p-o-s (as well as wvkbd, I presume) makes it so convenient to tweak just the algorithm without worrying about designing the keyboard itself.

Just a thought: maybe the swipe input varies also depending on whether we're using p-o-s vs wvkbd? I just took your default qwerty keymap but maybe I should see if that needs tweaking.

@agx

@badrihippo @agx technically the wordlist the makefile creates is not perfectly optimized for p-o-s or wvkbd (>= 0.14) because the bottom row is not staggered. (changes needed for mapScore). But right now, the two should work the same... aside from p-o-s reacting to text-input-unstable hints.

@zachdecook what's a hitbox? 😅

Side note, I've been meaning to sit with your algorithm to understand it; maybe I'll do that now. Not familiar with C unfortunately but this seems small enough I should be able to figure it out.

@agx

@zachdecook @agx I think my problem is more like I'm getting too many letters as input to swipeGuess. But I could be mistaken. What are your raw "hey swipes" like (so that we can compare)?

For me, I just tried to swipe "hey" a few times and got hgrery, hgrery, hgfrewety, hgrewery, and hgre as raw input. Corresponding swipeGuess suggestions are: greenery, greenery, (nothing), brewery, and here/hire/hare (I'd say the last one is just a bad swipe though)

@badrihippo No need to restart the shell, just restart (kill) the keyboard (otherwise development would be way too cumbersome).