Support for glide typing? #3
Comments
|
I thought about this, but I'm hesitant to leave this dependency, even on those phones that have Google apps installed. The ideal thing would be to reimplement the swype logic in the library. |
|
AnySoftKeyboard have swype support which is FOSS, but the last time I tried it, it's far from good as gboard or any of other proprietary swype IME. I think it's not worth the effect to implement this feature for now. But if you can add swype support and "joystick delete", it would make the keyboard much more usable. Joystick delete is a feature included in gboard but not enabled by default in stable (enabled by default in testing which require GApps to automatically get the config). With joystick delete, it show you a stick when you press the "Delete" icon, you can select words if you immediately swipe left, lift up to delete. or long press to quickly delete. |
|
Maybe implementing the space swipe gestures(select & delete) could be a good start point. It is already implemented in SimpleKeyboard (https://github.com/rkkr/simple-keyboard). |
|
oh I didn't know the delete swipe feature in Simple Keyboard before, it's exactly the same thing gboard have, joystick delete is just a visual stick which is not necessary. |
|
Moving the cursor by swiping on space would also be very nice. |
This is already implemented together with delete swipe, but the F-Droid build system takes several days to compile the new versions. The Play Store version is already up to date and has those features. |
Nice, thank you! |
|
Hi, But about that gliding - is there any workaround I could do by myself to enable glide? I'm not asking you to implement some options including that lib, but maybe you can just don't cut it from AOSP Keyboard? |
I actually disabled swipe from code, so even if you put that library it won't work. If time permits, I want to reimplement the swipe logic (no ETA though). |
|
@dslul is there a way to re enable swipe? i can re-compile myself. |
Just change here the library's name to jni_latinimegoogle and then enable gestures by setting sHaveGestureLib=true |
|
should i change |
|
changing |
Do you have that library in your system? |
|
Set I'm using LineageOS 17.0 (Android 10) unofficial, maybe it's ROM related, I have tried to put libjni_latinimegoogle.so into system, but the built-in AOSP keyboard always crash when swype. @dslul or anyone could try to remove libjni_latinimegoogle.so and include the so file in the apk and check if it could work?
|
of course. i think it said something related to emoji in the logcat; maybe a mismatch in method names? i tried with the library from opengapps for android 10 and 9. |
|
i've since read the source code of a different AOSP-based keyboard and it seems |
|
Is there an (un)official solution to get glide typing working? |
Not in openboard, in other AOSP-based keyboards, yes |
Are any of them FOSS? |
|
Keyboard itself is, but it requires proprietary libraries for swipe to work. Only OS keyboard with swipe is ASK. |
|
Yeah and ASK sadly has been horrible to use in my experience, even without swipe :( |
|
Does anyone know if Google's proprietary library has any data collection/network accessing code in it? |
|
I came across the following zip: https://forum.xda-developers.com/android/development/fix-cm-aosp-keyboard-swipe-fix-zip-t3182789#post83552617 but I don't think that it should work anymore, since the binary is for 32-bit and most phones are now arm64, I think. But perhaps it can help as a fix. |
Added spanish translation
|
Shame I would love the gliding even though the only option will be to use a proprietary google library, can we have an experiment with this ? In a fork/branch or something just to see how good or bad it is .. maybe with in-house glide typing as well like in ASK. |
|
Including proprietary closed source libraries in the app is not going to be accepted on F-Droid. The only way that may work is allowing the user to provide a library via app settings. |
|
...or maybe just add it to izzysoft's repo. |
|
Helium314 makes a good point:
People ask for F-Droid inclusion because their system ensures no difference between published source and apk. As far as I understand izzysoft 'simply' packages pre-built apks and makes them available as a repo for the F-Droid client. In short, izzysoft is a convenience service and there would be little difference between that and downloading a manually built apk from github. Personally I could be OK with installing the library manually, but I suspect this would quickly turn into a chore for those running Lineage, as it'd probably entail reinstalling the library every week, whenever an update package is released. If the app could download the library from a trusted source and provide the user with a way to trigger the download/install manually, that workaround would be fine with me. However I wonder if that's actually feasible? |
|
FTR, I am basically forced to use OpenBoard as it's the least bad, usable FOSS keyboard for languages other than English. However, it is a very frustrating experience, and the issues list paints a fairly grim picture, of a stagnant application that is missing what might be considered basic QoL features. This is to say I, and I believe many others who are in the same predicament too, would very much welcome a fork with a more dynamic, pro-active approach that's willing to listen to the wants of those users who employ OpenBoard as a daily driver. The base is solid, so it's not so much a matter of major overhauls but rather minor tweaks to improve QoL. |
|
Why is a fork necessary? I haven't seen any reason to believe that a PR to add glide typing would be rejected. |
|
Glide typing is not necessarily something that I would consider a basic QoL feature, although it could perhaps be implemented in a relatively simply fashion - but I'm not going to repeat the whole discussions again. The reason I used this issue is because some folks had already forked OpenBoard, so it seemed like a decent place to send that message in a bottle.
Then perhaps you should read this issue from the beginning? The original developer (still part of the openboard-team) stated their wish was to reimplement glide typing from scratch, doing which in a fashion that is considered good for everyday use, is already a huge task on a good day, and obviously won't ever get done if even much smaller things are left to languish for months on end. Just to mention one such smaller issue that is nevertheless highly irritant, OpenBoard will learn incorrect spellings and there is no way for the user to fix those mistakes without resetting the whole thing. Another issue I'm encountering on a constant basis is OpenBoard adding spurious extra blanks when making a certain type of correction. It does seem that there is a PR for this last issue, which however has been left collecting dust for 3 months and is part of roughly 20 other unresolved PRs, among which some being a year old and maybe more. All of this, and additionally the slow release cycle, and sparse activity from openboard-team, suggest that there might be not nearly enough dogfooding of OpenBoard. So, this is about encouraging those folks with a can-do attitude who already forked and actively worked on OpenBoard, to let them know that a better OpenBoard would be greatly appreciated, if they're willing and able to take up the challenge. |
Only saw this now, sorry for the late reply: Such a thing may qualify as acceptable for F-Droid, but allowing to load an arbitrary file to be executed is still a security risk...
Well, it would considerable re-arrange the locations of code files (see wordmage fork), and it would require a library to be either distributed with the app (closed source, maybe legal issues) or provided by the user (hacky, security issue), or to actually re-implement glide typing (massive amount of work).
Most of them are requests for adding dictionaries. I remember those are not merged because they would increase apk size considerably. There also is a PR/branch for allowing to add dictionaries from files that would improve the situation, but it also seems to be collecting dust. I have the general impression that a) OpenBoard is getting a bunch of new weird bugs/issues with every new Android version and b) the maintainers simply don't have enough time (and maybe new enough Android) to fix those, and even less to add new features. Actually I have some more changes in my version of OpenBoard, but seeing the slow progress of other PRs I don't want to spend the time necessary to make them ready for a PR (translatable strings, use of preferences instead of hardcoding everything,...) |
|
I notice this commit can help? It seems that the closed library of google is not used. LMODroid/platform_packages_inputmethods_LatinIME@bd28487 Is it good for something or is it a useless commit? |
This can be tested. I'll be giving it a shot after lunch today. |
|
It works. No Google libraries are added in. I've pushed the necessary changes to my fork, along with the aforementioned commit. This is much cleaner and I personally think it can be shipped with an OSS build of OpenBoard. |
Fantastic, i was convinced it was a good commit. |
|
The new files don't have license blocks, and they include this comment: Since the oldest source of this code that we know of has no license associated with it, we definitely can't assume that it was developed under an open source license. Please try to be careful about where you get code from. |
|
@nift4 @iKeramat @shijieKika Can you provide details on where the glide typing code came from? |
|
You already found the repo - while there is no license file, I simply assumed it is Apache2 licensed. I'm aware that's technically not how it works, and I don't except anyone to merge that code, I personally am happy with this solution and I don't care if the license is not properly defined. The repo has not been taken down in five years, and the commit history very much looks like the chinese developer did the code himself - and he chose to upload it for the public - that's all i cared about when porting those commits. |
|
Also note that the last commit is called |
|
It's probably nothing to merge as is from the POV of an big project like OpenBoard indeed. Maybe someone will reimplement it based on the ideas of this example code, or maybe a fork with the patch will have to do. |
|
On a slightly related note, most new files are partially modified copies of the typing/ folder variants, not all-new code. |
|
Yes but the published code is open source on github, it has no license and therefore I don't see where the problem lies and in the end it works. This kikatek keyboard is closed source, but the code we are interested in is opensource and there is no license or anything else that forbids to use it
|
|
At least by US law (not sure about other jurisdictions) code without an explicit license has all rights reserved, which means you can't use it. Open source is not the default. |
|
@Helium314 thanks for the answer, very interesting.
I could name at least another FOSS keyboard that has solved that problem by distributing the languages as optional components. Sad to see OpenBoard hasn't progressed any, though, it's still my daily driver. |
|
Ok, I didn't know this US law, even if we are not US.
|
|
I did find the licence for the code dubious while working on it. Despite that, the code does allow for some pointers to wiggle the progress on gesture input. At the end of the day, we can either work with this, reverse-engineer Google's solution (which we now know can be done from GBoard v7), or develop our own. I don't have time to do the last two options, unfortunately — this is the reason why I don't release my fork to begin with: I'm only comfortable with using it for my personal use (and this commit serves a good enough replacement for the aging library for now). |
Works like a charm! |
|
@wordmage 's @erkserkserks Could the gesture fork be ported to v1.4.5 of OpenBoard, respectively could the chnages be merged in there? https://github.com/openboard-team/openboard/releases/tag/v1.4.5 |
and others
AOSP keyboard have settings for glide typing but does not included in OpenBoard.
I know it's because glide typing require
libjni_latinimegoogle.sothe proprietary library (it can be extracted from OpenGApps Optional/swypelibs-lib-arm64.tar.lz).But maybe consider add this feature to Play Store version by using product flavors? Since play store users probably already have GApps on their phone. and the repo does not need to include the proprietary library, f-droid flavor could just keep do not include glide typing support. Including such feature does not seems break anything if the OS does not have
libjni_latinimegoogle.so.I'm also trying to build LatinIME, but can't get glide typing works for me (but it works on LatinIME in LineageOS). it's a bit strange. so you may make sure at least it works on your devices if are about to support this feature.
The text was updated successfully, but these errors were encountered: