While *.kmn and *.kps compile w/o errors, during the installation on an android device I get an “Error in keyboard” message.
The message does not appear on an iOS device.
The kbd works fine apart from the appearance of this message.
Any ideas? Some error message?
Thanks in advance
I have sometimes seen an error if the language tag is not correct, or even if it’s missing the language tag. That is what is set in the .kps file on the “Details” tab.
Very interesting.
Before I compile the package I always verify that the BCP-47 tag and the language name are set as in the attached screenshot.
Anything missing?
— Note: Email replies will be posted to the SIL Software Community Site —
| Lorna
July 9 |
- | - |
I have sometimes seen an error if the language tag is not correct, or even if it’s missing the language tag. That is what is set in the .kps file on the “Details” tab.
That looks correct. I’m not sure what the issue would be.
@darcy is currently away, but he would be the person to investigate that error in more detail. If you have ‘Allow sending crash reports over network’ enabled in Keyman for Android settings, then we will have a copy of the error report, and it’d just be a matter of locating it on our end. (I am also mostly unavailable for the next couple of weeks, sorry!)
OK. will do.
‘Allow sending crash reports over network’ is enabled.
Also I am in communication with Darcy concerning localization in Polytonic Greek, so we will include this issue in our exchanges.
Thanks a lot both of you.
@amadel - what version of Keyman for Android are you using?
Also, could you send me a Direct Message with a link to your.kmp keyboard package file so I can test locally?
I just sent you the reply via a conversation from crowdin.
Concerning the language tag:
I have selected “el” which is supposed to be Modern Greek (1453-)
This is supposed to be different from “grc” which is Greek up to 1453.
In other words somebody decided that modern greek starts in 1453. Anything before is “grc”, anything after is “el”.
However, up to 1982 the script used by everybody in Greece was polytonic, i.e. the script used in ancient / medieval Greek, therefore by classissists as well. In 1982 a law was passed that dropped some accents for simplification, yet many writers, poets, the Church, and many untalented people like myself(!), still use the polytonic script. For this reason, I selected “el” as a language, but the keyboard is addressed to anybody! Greeks for everyday use, classissists of any nationality, etc.
I hope this clarifies a bit the mess…
A.
— Note: Email replies will be posted to the SIL Software Community Site —
| darcy Keyman Team Lead
July 12 |
- | - |
@amadel - what version of Keyman for Android are you using?
Also, could you send me a Direct Message with a link to your.kmp keyboard package file so I can test locally?
I can duplicate the error notification on my local device too.
We’ll investigate this as issue #119625
Late during 17.0’s development, we did some optimization work to speed up the initial loading time of keyboards for our mobile apps. It looks like one of the changes made at the time has unintended side effects for keyboards compiled with “debug mode” - which is enabled within the keyboard package you sent us - and that complication is causing the error.
Fortunately, the way things are structured still allows things to work normally for you - the one issue being the error message that pops up. (There’s a fallback mechanism in place that is allowing the keyboard to recover successfully.) The keyboard is completely safe to use - we just need to polish up that optimization work a bit further so that the message you’re seeing no longer occurs.
The most likely way forward for this will probably prevent one of the optimizations we’ve applied from working, so if you feel the keyboard loads a bit slow, I’d still recommend getting a version of the package that is not in “debug mode”. It’s not critical though - and even then, it’s only one of the many keyboard-loading optimizations we added in 17.0.
tl,dr: Don’t worry - we just need to polish things up a bit.
Hi, again and thanks for the info.
Fyi. I recompiled the keyboard with the debugger stopped. The error still appears at installation / load time.
A couple of details concerning Keyman Developer:
(a) The language tag is removed and I need to reenter it.
(b) The paths to the .kmx, .kvk, .js files are changed from kbdname\build*.* to kbdname\source..\build*.*. I then have to remove and add them again with the correct path.
This is not a serious problem, but I thought it would be interesting for you to know about.
Concerning loading time: I have not noticed any delays. I presume that the loading time only matters for the first time the kbd is used, because afterwards it sits in memory. Is this so? Would it make sense to reduce the kbd size by removing the images I have included in the welcome screen of the kbd? (I could probably direct the user to a help page in my site for this same info). What do you think?
Once again I want to thank all the members of your team for your prompt response.
— Note: Email replies will be posted to the SIL Software Community Site —
| joshua_horton
July 15 |
- | - |
Late during 17.0’s development, we did some optimization work to speed up the initial loading time of keyboards for our mobile apps. It looks like one of the changes made at the time has unintended side effects for keyboards compiled with “debug mode” - which is enabled within the keyboard package you sent us - and that complication is causing the error.
Fortunately, the way things are structured still allows things to work normally for you - the one issue being the error message that pops up. (There’s a fallback mechanism in place that is allowing the keyboard to recover successfully.) The keyboard is completely safe to use - we just need to polish up that optimization work a bit further so that the message you’re seeing no longer occurs.
The most likely way forward for this will probably prevent one of the optimizations we’ve applied from working, so if you feel the keyboard loads a bit slow, I’d still recommend getting a version of the package that is not in “debug mode”. It’s not critical though.
I’m not sure your current status, but based on your above comment:
In Keyman Developer, Project Settings, make sure the output path is:
$PROJECTPATH\build
Then, you should recompile, then go back to your .kps and load the compiled files from you kbdname\build folder rather than kbdname\source\build.
Once you do that, you may have to re-add the language tag in the Details tab.
The build folder should never be in the source folder and you should delete that folder so you aren’t tempted to load the compiled files from there.
Hi, Lorna,
This is exactly what I am doing.
Once more here is what happens: after the project “build all” is executed the paths of the input files of the package are changed from build*.* to source..\build*.*
Concerning the language tag, this is removed when I remove the files with the wrong path in order to add them again with the correct path.
Note: this is not a serious problem for me, because I know how to bypass it. I only mentioned it because it may help debugging/fixing the “error in keyboard” problem.
Best regards,
— Note: Email replies will be posted to the SIL Software Community Site —
July 17 |
- | - |
I’m not sure your current status, but based on your above comment:
In Keyman Developer, Project Settings, make sure the output path is:
$PROJECTPATH\build
Then, you should recompile, then go back to your .kps and load the compiled files from you kbdname\build folder rather than kbdname\source\build.
Once you do that, you may have to re-add the language tag in the Details tab.
The build folder should never be in the source folder and you should delete that folder so you aren’t tempted to load the compiled files from there.
The path source\..\build is the same as build, so that’s all good.
This is so. The keyboard will occasionally be reset by your system - say, if it hasn’t been used in a while - but only the first time matters each reset.
The delays mentioned are generally fairly short, though they usually are a bit noticeable on Android devices. Unless using an older, lower-performance device, it could be about a couple of seconds or so, depending on how complex your keyboard is. We’ve shortened this delay in 17.0.
The welcome screen and its resources do not affect the keyboard loading time whatsoever. It does affect downloading time, naturally, but not loading time.
This topic was automatically closed after 7 days. New replies are no longer allowed.
