The nextlayer property on a key in the touch layout overrides output about keyman HOT 3 CLOSED

Furthermore, trying to use nextlayer to move from a custom layer to a default layer (e.g. "shift") is broken, see the code in osk.updateLayer. I don't know why this code is like this and we probably need understand why the code is doing this before we fix this. The same workaround applies.

from keyman.

This is my biggest blocker bug, and I don't think it is truly closed.

I see you fixed this bug in KM web. #116

I also see your workaround of using layer() in the source. The workaround didn't work on android for long-press items, but maybe it does now with #116 .

As it seems to me:

1. The ugly workaround only partially works (because of longpresses), and
2. Using NextLayer the normal way (in KD) doesn't seem to work at all (it jumps to the layer before outputting the text).

So where are we now on this bug? Should I still be using the ugly workaround, or is this bug fixed in any current Android/iOS alpha versions?

from keyman.

Note that both our Android and iOS app use KMW as their core; our Alpha versions of both apps should no longer have this issue. If you'd like to investigate this for yourself, please check our links for the alpha versions on https://keyman.com/downloads/pre-release/ for details on how to get our in-development versions. We've tested this and fixed it to the best of our knowledge in the most current alpha versions for both.

Note that we're in the midst of a big overhaul of our products in preparation for a new major version; unfortunately, this means that #116 will not be 'released' for quite some time. If this is something for something you'll likely need in the next couple of months, I'd advise continuing with the workaround for now.

Also, would you mind sending us a copy of the problematic keyboard source so that we may use it for testing to ensure the issue is properly resolved for future versions?

Thanks for your feedback on this!

from keyman.