@capybara and I have run into issues when testing the keyboards that we have been working on, both using Keyman Developer 17.0.326. We both have tried saving, compiling, recompiling several times and we can see that the .kmp has been updated recently, but the changes made are not reflected when we install the packages. This issue is affecting mobile and desktop.
Happy to provide more info as needed, thanks in advance!
Hi @HopsAndHops, I’m not sure what is happening; here are two ideas:
Have you been recompiling both the .kmn and the .kps files?
Is it possible that the .kps file is referencing the wrong compiled .kmx file?
If those don’t help, can you share your keyboard project with us and tell us the exact steps you are taking when building and installing the keyboard, so we can try and reproduce what is happening here?
Thank you for the suggestions! I went back into the .kps to check the referenced .kmx file, and it was correct. I removed it, added it back in and received a warning message about conflicting versions. I recompiled the .kmn, then the .kps, and now it installs as it should.
I still have access to the .kps that wasn’t installing correctly before - would you be interested in taking a look?
We have a weird problem, and I’m wondering if it might somehow be related to this issue. We recently changed our keyboard version number from 5.2 to 5.3, and if we look at the .kps source, it is appearing correctly:
But if we open the file in a text editor, it still shows version 5.2:
The modified date on this file is older, and doesn’t reflect the date the version was changed to 5.3.
The file is stored on our local server, and we are using a UNC path to access it. In fact, we are getting a warning when we build all:
sil_tchad_qwerty.kmn - info KM00000: ‘\cdb.silchb.org\Server\Data\Language Technology\Keyboards\sil_tchad_qwerty\source’
sil_tchad_qwerty.kmn - info KM00000: CMD.EXE was started with the above path as the current directory.
sil_tchad_qwerty.kmn - info KM00000: UNC paths are not supported. Defaulting to Windows directory.
sil_tchad_qwerty.kmn - info KM05002: Building //cdb.silchb.org/Server/Data/Language Technology/Keyboards/sil_tchad_qwerty/source/sil_tchad_qwerty.kmn
sil_tchad_qwerty.kmn - info KM05006: //cdb.silchb.org/Server/Data/Language Technology/Keyboards/sil_tchad_qwerty/source/sil_tchad_qwerty.kmn built successfully.
sil_tchad_qwerty.kps - info KM00000: ‘\cdb.silchb.org\Server\Data\Language Technology\Keyboards\sil_tchad_qwerty\source’
sil_tchad_qwerty.kps - info KM00000: CMD.EXE was started with the above path as the current directory.
sil_tchad_qwerty.kps - info KM00000: UNC paths are not supported. Defaulting to Windows directory.
sil_tchad_qwerty.kps - info KM05002: Building //cdb.silchb.org/Server/Data/Language Technology/Keyboards/sil_tchad_qwerty/source/sil_tchad_qwerty.kps
sil_tchad_qwerty.kps - info KM05006: //cdb.silchb.org/Server/Data/Language Technology/Keyboards/sil_tchad_qwerty/source/sil_tchad_qwerty.kps built successfully.
But it seems to build and update the files in the build directory.
We have closed Keyman Developer, our editors and even disconnected from the server and reconnected, but when we open our project with Keyman Developer, we still see 5.3 in the .kps source, but the .kps file on the server is not updated - the date is older and a text editor still shows version 5.2.
How is this even possible? Doesn’t Keyman Developer read the .kps file from the disk when it opens? How can the Source of the .kps be different than the .kps file found on the disk?
We would appreciate your help figuring this out - last thing blocking our keyboard submission!
We ended up changing the version manually with a text editor, so we could continue with the submission.
My guess is that there is a bug in Keyman Developer, that when you open the package file, maybe it gets some information from the .kps file in the project folder but gets info on the keyboard from the .kmn file? If there is a difference between the two versions of the information (like the version), it won’t necessary notice that there is anything to change, so it doesn’t mark the .kps file with an asterisk (modified), and doesn’t save it out to the disk. I assume if we had changed something else in the package, it probably would have saved it out just fine.
Not a huge problem, but a bit annoying and could be confusing.
Jeff
The recommended process is to change the version number in the .kmn file (Keyboards, Details tab), leave the version number field in the .kps file blank and tick the “Package version follows keyboard” box (Packaging, Details tab).
I made a quick test: with version 1.0 in the .kmn file, version 2.0 in the .kps file AND the “Package version follows keyboard” box ticked in the .kps file, the resulting .kmp has version 1.0 in the .inf file.
Something similar could happen if the version in the .kmn file were updated, but the .kmn file wasn’t recompiled.
The version information in the .kps is actually not used in this scenario – the compiler always pulls the latest version from the .kmx when building. Long-term, we’ll probably remove that field entirely from the .kps to eliminate the confusion.