Are there any keyboards on f-droid that offer word prediction?
I always go back to SwiftKey (but didn’t update if since they announced AI stuff) because nothing comes close, but I would gladly change it to something FOSS.
@fri I'm using AnySoftKeyboard. Took me a bit of getting used to and I'm probably still less efficient than I used to be, but it doesn't send what I type to remote servers to train AIs on. @Hirom
Homepage is @ https://github.com/Helium314/HeliBoard (and it links to the page that contains that binary library, including other architecture versions).
I’m still looking for a keyboard with predictions which doesn’t require me to change languages manually. I’m currently on Gboard as there is no decent alternative.
Unfortunately (and incredibly) Gboard is the only keyboard that fits all my needs. I’m on graphene so I feel ok about just blocking its network access. This means voice transcription doesn’t work, but otherwise I get swipe, predictions, and other languages.
The biggest thing keeping me from switching away from Gboard are things like the Japanese and Chinese IMEs. I have yet to find an open source keyboard with both of those, while also allowing me to switch to English.
Edit:
Clicked on the article. Clicked on the Trime and Fcxit5 and plugins links. It might be suitable in the future. Hoping this isn’t a situation where I finally find a solution and then the devs suddenly disappear without a trace.
I was in your shoes for ages, but HeliBoard has predictions and other languages out of the box. Voice transcription works if you have FUTO Voice Input. Gesture typing uses a swypelibs binary extracted from Gapps; you just have to download it manually since the app never requests network access (instructions are on the Github page). I started using it today and some of its features actually seem to work better for me than Gboard, like the swipe gestures on delete or space, and it has at least a few more features I’m pretty sure Gboard doesn’t. Give it a look at least.
The typing scheme is highly innovative and the code they used to do it is proprietary so its a little hard to get started replicating. Further, they have a design patent that means you need permission from the company and licensing to replicate that action. The way they do this licensing and permission means its FAR easier to get that permission and include the proprietary binary blob than to reinvent the mechanism. I’m sure there are extreme radical FOSS-heads interested in doing this with code they’re working on, but any big project that wants to create a legitimate daily driver keyboard is going to be more focused on other problems surrounding ethical predictive text and the precision of screen taps. Like this is more a question of what problems are worth solving than anything. There’s plenty of hard problems in the mobile keyboard space that don’t involve lawyers, especially when getting access to the Swype lib to embed in keebs has thus far been pretty trivial and that lib has been found to be not gnarly in audits.
Personally I do have worry about Swype doing a rugpull with this licensing to keyboards that are using it, since that’s one of the paths of enshittification/rot-econony, but I also wouldn’t choose not to use a keyboard without swipe gestures (in fact my current keyboard doesn’t have them because I can type fine enough without them and its one less thing to install or worry about)
Add comment