Fixes#9708.
Matches the kmp.json format of keys string in the .keyboard_info schema
and compiler, in order to reduce the number of formats we are working
with. This same format may be used elsewhere in Keyman schemas in the
future for sets of keys, for example, I hope we can use it in regression
tests.
Fixes#9478.
This adds a property WelcomeFile to .kps and kmp.json, which allows us
to move away from the hardcoded welcome.htm filename in the future, and
makes transform from Markdown (#9477) a simpler operation, and just
generally starts the cleanup of the messiness of hard-coded filenames.
The package compiler will fallback to injecting welcome.htm into this
property if (a) welcome.htm is present, and (b) the property does not
already have a value. This doesn't buy us much because we still need to
support welcome.htm for existing legacy packages, but does mean that
our .kmp package metadata will be more consistent for packages compiled
with 17.0+ compilers.
Fixes#9620.
.keyboard_info keys emitted from kmc-keyboard-info had the wrong format
for the example.keys object, which I discovered when I applied the
validation to the kmc-keyboard-info output.
Relates to #9351.
Adds support for building a .keyboard_info file without having source
.keyboard_info file:
* Constructs a default source .keyboard_info in memory
* Hints if license is missing
* If LICENSE.md is present, verifies it matches the MIT license text
* Adds project option to turn on or off metadata generation. This will
default to False for version 1.0 projects, and to True for version 2.0
projects. This means that the keyboard repository will need a PR to
enable metadata generation for existing projects in the repository,
but this is important to avoid breaking builds for existing projects
that are not in the repository.
* Turns on additional c8 coverage for kmc projects
Adds license file to .kps, kmp.json, kmc-package, package editor, and
new project templates. The intent is for LICENSE.md to be the file used,
and for any keyboards on keymanapp/keyboards, it should always be a
standard MIT license.
While a package supports a .ttf or .otf font for the OSK and Display
fonts for use within the Keyman apps, on websites it also supports .woff
and .woff2. This change makes it possible to specify a set of fonts for
a package which will be provided through api.keyman.com to websites.
This means that .woff and .woff2 fonts may also be included in the
package and may not be used on target devices at this time, it further
opens the pathway to deploying .kmp packages to web in the future.
The deployment stage of keymanapp/keyboards will require a new phase to
copy web fonts from packages to s.keyman.com.
Adds relatedPackages support to:
* .kps schema
* .kps file format for Typescript
* kmp.json file format for Typescript
* kmc-package compiler
* Package Editor
Removes the following fields:
* legacyId
* documentationFilename
* documentationFileSize
* links
* related[].note
None of these fields are needed any longer; see #9351 for steps to
remove data.
Eliminates difference between keyboard_info source and distribution,
renaming to keyboard_info.schema.json, and updating the required members
of the json accordingly.
Will have corresponding commits in keyman.com, api.keyman.com,
help.keyman.com, and keyboards repositories.
Fixes#9430.
Adds a 'default' property to subkeys, only used by longpress-type
subkeys:
* Added property to schema and readers/writers
* Added property to touch layout validator
* Added editor for property to layout builder
Fixes#9140.
Fixes#9148.
Keyman Developer 9.0 .kpj files included a lot of additional state
metadata. We need a schema which validates these files, as they are
otherwise valid to load (we'll never save them any more). Rather than
add all the extra metadata to what is otherwise a fairly clean schema,
we'll provide a legacy .schema.json.
In the future, we may be able to merge these schemas, as we move towards
the .kpj 2.0 format which doesn't list files. Ideally, all three formats
(Keyman Developer 9.0 schema, call it legacy, 1.0 schema for Keyman
Developer 10.0+ which has Options and Files listed, 2.0 schema for
capturing just project settings for a folder) will be supported by a
single schema file.
The &displayMap system store adds support for a mapping file that remaps
the On Screen Keyboard files -- .kvks and .keyman-touch-layout, at
compile time, to new ranges. This is specifically intended to resolve a
limitation of unattached marks and diacritics which display
inconsistently across platforms; this is described in more detail in
issue #9031.
Fixes#7340.
Removes the unused <Version> element from <LexicalModel> element in the
.kps schema. (This needs to be copied to api.keyman.com also.)
Updates compiler to check for <FollowKeyboardVersion> and read the
version data from the .kmx in that case.
Unit tests updated. Some of the fixtures were incorrect as they had
<FollowKeyboardVersion> set for model-type packages or packages that
contained no keyboards. Fixed.
Relates to #2761.
kmc now supports passing in a folder and building all Keyman source
files found in the folder, even if a .kpj is not present in the folder.
If a .kpj file exists, `KeymanDeveloperProject/Options/Version` will be
checked to determine behaviour. If this field is missing or "1.0", then
the classical behaviour persists.
If the Version field is "2.0", the `Files` key is ignored, and .kmn,
.xml, .model.ts, and .kps files under `sourcePath` are enumerated and
added to the in-memory project for build.
If a .kpj is not present in the folder, a virtual project is constructed
in memory with the following defaults:
* `version`: `2.0`
* `buildPath`: `$PROJECTPATH/build`
* `sourcePath`: `$PROJECTPATH/source`
* `compilerWarningsAsErrors`: `false`
* `warnDeprecatedCode`: `true`
* `checkFilenameConventions`: `true`
It is still considered an error to include both a keyboard and a model
in the same file, but a version 2.0 project will not include the field
determining its type in `Options/ProjectType`; this will instead be
checked during build.
The call to `kmc` can reference a folder or a .kpj file. The .kpj file
must have the same basename as the folder name (e.g.
`khmer_angkor/khmer_angkor.kpj`).
WARNING: this does not add support for 2.0 projects to Keyman Developer;
it is likely that opening a version 2.0 project in Developer will
currently corrupt it.
WARNING: it is not anticipated that kmcomp.exe will be updated to
support version 2.0 projects -- rather kmcomp.exe will be removed before
release of v17, and replaced with kmc.
Also splits attributes from sub-elements in kvks-file in order to make
round-trip writing more pleasant.
Adds new round-trip test for kvks writer.
Removes incorrect property keybitmap, adds missing property layout.
After a demo of the Touch Layout Editor @jahorton suggested using a
"default hint" model instead of the "display hint" from the design spec.
I liked this and have reworked the design accordingly. With the default
hint model, a source for the hint text can be specified, such as the
default longpress key, or a specific flick key. This can then be
overridden on a key level.
The hint input element now shows a placeholder to indicate the default
hint for the key, and if a hint has been customised for a given key, it
is shown in green on the key cap.
Changing the default hint does not impact any customised hints.
Improves the .keyman-touch-layout clean schema and adds additional
cleanup during load and save in the Touch Layout Editor.
The compiler already does transforms for the relevant fields to the
formats that KeymanWeb is expecting (in particular, width, pad to
string).
This is preparation for adding hint data to the format as well.
Fixes#5464.
The keyboards repository already has code to validate .xsd files, using
xmllint. This adds the same functionality directly into kmcomp and TIKE.
