Is there a way to customize the long-press delay time for Android and iOS? That would be very helpful. It currently defaults to about 1000 milliseconds.
iOS Keyman 10.0.145
Compiled in Windows Keyman Developer 10.0.1056.0
Thank you,
James
Raine, Did you have any luck?
Is there a way to customize the long-press delay time for Android and iOS? That would be very helpful. It currently defaults to about 1000 milliseconds.
@lss_png Thank you for the suggestion. I’ve created issues #877 for Android and #878 for iOS.
We’re nearly done adding new features for 10.0 Beta so this likely would be in a future version.
Raine, now that Keyman for macOS includes some error reporting, it may well be that if you install the latest beta version we’ll be able to see what is going wrong.
The OSX display for keyboard information (i) appears not to handle UTF-8 text (v10.0.46). It may be that it does, but uses a limited font. Note the "?"s next to “(Amharic)”, the copyright symbol is then a black diamond with a “?” inside.
Another note, the .dmg file uses 10.0.46 in the filename, but keyman declares itself to be Version 10.0.44 (build 10.0.44).
This was fixed in 10.0.47
Hello.
I am using Keyman Desktop 10.0.44 on MacOS 10.13.4 using my own Swedish keyboard layout.
Keyman seems to do its work in two ways, presumably depending on what the client software supports.
When I use it with native Cocoa applications it works well, but for a lot of other applications (Firefox etc) Keyman appears to revert to a “insert and delete”-mode, i.e. a "o"+"e" -> "ö" rule first outputs “oe” which is then deleted and replaced with “ö”. When typing fast (which I do most of the time) additional characters typed after the ö typically gets intermingled, i.e. if I type “öl” I get “lö” because the “l” somehow gets inserted before the “ö”.
In a naive input method implementation I can see how this would happen (characters are queued up asynchronously), but to be correct somehow Keyman needs to arrange things so that the “ö” is sent to the client application before the “l” because the “o” and “e” was typed before the “l”.
Any plans to make Keyman open source btw?
Any plans to make Keyman open source btw?
Yes, here’s the Keyman open source announcement which has the link to our source in GitHub.
The Keyman keyboards repository is also available at GitHub - keymanapp/keyboards: Open Source Keyman keyboards
1 Like
Yes, it’s clearly an issue. It’s also difficult to solve. The input queue is asynchronous and not lockable, making race conditions almost unavoidable. Because we are posting events to the same queue from which we receive those events, and we have no control on the order of events posted, it’s always going to be tricky to get it right. We always welcome more eyes on the code (GitHub - keymanapp/keyman: Keyman cross platform input methods system running on Android, iOS, Linux, macOS, Windows and mobile and desktop web)!
@TomB would also be interested in discussing this further.
I see. That is certainly a showstopper for me. If I understand things correctly the only way to remedy the situation is to patch the offending applications so that they support the text replacement APIs (short of asking Apple to make the async api more featureful).
It may be that we can improve things in an update – we’ve managed similar compromises in the Windows code but it’s pretty hairy and there are still some edge case race conditions with modifier keys that are hard to resolve. Certainly the best way forward is for apps to support the text replacement APIs; that also gives Keyman access to the context of the text store so that it can apply contextual rules wherever the insertion point is placed.
Marc’s analysis is correct. I would love for more apps to adopt Apple’s text replacement APIs. That’s clearly the best way forward, but it is obviously one over which we have no real control. A (less than ideal) workaround if you’re trying to type a lot in an app that doesn’t work correctly would be to type your text into a compliant app and then cut and paste into the app that doesn’t work as well. Obviously, that’s not much of a solution if you’re typing a lot of really short bits of text. It might be possible to tweak the timing values in Kayman for macOS to work better for you, but because the speed of operations is dependent on hardware, software, user typing, and current system load, tweaking to make it work slightly better in one situation might break it completely in another.
Before Keyman was released for macOS I implemented my Keyman-based input method myself using InputMethodKit. It only makes use of text replacement and performs better than Keyman Desktop in certain applications (such as Apple Pages and Firefox, where Keyman Desktop appears to suffer from async timing issues).
Any idea why?
@tgerdin, we’d welcome your ideas and suggestions on improving performance and reliability; the code is all open at https://github.com/keymanapp/keyman. Or if you are willing to share your code with us, we can maybe learn from that?
Yes, I really appreciate that Keyman is free software now. When I have time I may look into this, but for the time being I will just point you to the code repository which I think contains the actual working code: <link here, except it says "New users cannot put links in posts>???
As you can see it is extremely bare-bones, so no surprise that it’s swifter than Keyman proper.
Even so, everything is synchronous and seems to work with some apps (Firefox, Pages) where Keyman switches to async input for some reason. To determine why would be very beneficial I think.
I’ve upped your “trust level” so you should be able to post links now I hope!