TWIF generated on Thursday, 25 Apr 2024, Week 17Community News@linsui is forced to tap the sign:We are sad to read articles like the latest one from The Citi...
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.
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)
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.
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.
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.
Cool, will do. It’s weird to me that open boards need to pull the swype binary. Is it really that hard to replicate?
Put simply: yes
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)
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 do exactly the same. It’s the only Swype that works reliably for me