Fixing up a number of minor bits and pieces identified during demo:
* invalid action or :target would not be picked up if paired with a
valid one (e.g.: build:foo should not have worked)
* colors defined in both shellHelperFunctions and build-utils were
problematic; able to remove them from shellHelperFunctions because
all references included both scripts
* builder_has_action and builder_report now allow both `action:target`
and `action :target`
* keyman-version/build.sh did not have working test action...
builder_init was unnecessarily and inconsistently duplicating
builder_describe and builder_parse functionality. Removing it -- all
scripts should use builder_describe and builder_parse instead, which
gives us more flexibility and consistency into the future.
Fixes up scripts (except under /linux) to use `#!/usr/bin/env bash`
instead of `#!/bin/bash` or `#!/bin/sh` so that we don't end up with
the ancient version of bash supplied with macOS.
This became urgent with this PR, because of bash-4.xisms in
build-utils.sh, for example on line 572:
```
if [[ -v _builder_params[$e] ]]; then
```
Adds support for :target and --option to the builder_() functions in
build-utils.sh, along with a consistent way of describing command line
parameters in short-hand form, so we can avoid the display_usage getting
out of sync with actual command line parameters.
I opted to tweak the existing usage slightly, reversing parameter order
for `builder_report`, so that we could extend `builder_report` cleanly
to support targets.
The new builder_() functions are `builder_describe` and `builder_parse`,
which should be used in place for `builder_init` where you want to
provide more detailed command-line options (for many scripts, the
defaults provided through `builder_init` may suffice).
`builder_describe` lets you set a single-line description of the script,
along with a list of parameters: `actions`, `:targets` and `--options`.
Options may also specify a shorthand form, e.g. `--option,-o`. Each
parameter may optionally include a short description, separated by
space(s) from the parameter name.
build-utils.test.sh tests the functionality of the various functions,
and provides some examples of using them.
Defaults:
* If a target is not specified in `builder_describe`, a standard target
of `:project` will be available.
* If the user does not pass an action on the command line, then `build`
will be used.
* If the user does not pass a target on the command line, all targets
will have the actions applied.
Note, it is possible to have targets which do not use all actions. These
may be still be specified, but can be ignored. For example, `test:tools`
may not be an action:target that you handle in the script. At this time,
the builder_() functions do not attempt to check for this.
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.
Adds kmdecomp to kmcomp-<version>.zip and fixes a couple of stability
issues:
* Increase buffer sizes (this fix very much a hack)
* Ensures that .bmp/.ico files are saved to correct output folder
* Disable loading sentry.dll when running on WINE
Fixes#6910.
Regression introduced in #6874 / #6849 (which themselves were improving
the Caps Lock situation).
Ensures that either `NO_CAPS` or `CAPS` is always set in the modifier
flags.
Fixes the release build where we do `nmake symbols` for developer/src,
which was failing on calls to these two sets of components. (In
windows/src, the build structure is different due to an additional layer
of folders, so we end up with no `nmake symbols` call on the common
components).
The back story:
Currently Keyman for Android reports errors sent to the console via
`console.error()` into Sentry but sentry-manager itself does not. This
means that Keyman for iPhone and iPad and other users of sentry-manager
do not report these errors. Many of these errors are important.
What's worse is that Keyman for Android's error reporting here (via the
`sendKMWError()` function in Keyman Engine for Android) does not capture
stack traces, and so many of the errors we get do not have enough
information to resolve them.
Furthermore, by having `sendKMWError()` in Keyman for Android, we
capture exceptions and other program errors twice -- once on the web
side, and once on the Java side -- this adds noise to our error
reporting. Sentry also tends to lump many unrelated `sendKMWError()`
events together, so tracking resolution to the errors is painful.
The fix:
This adds a patch to sentry-manager to capture `console.error()` and
`console.warning()` events and report them through Sentry's normal error
reporting, and disables the `sendKMWError()` report (although we leave
the breadcrumb in place for when there are later, related Java errors).
There is a Sentry integration called CaptureConsole, but it does not
support capturing stack traces until v6.14
(https://github.com/getsentry/sentry-javascript/pull/4034). Updating
Sentry to 6.14 or newer is a bigger job (due to ES6 baseline req. etc.)
Note that Keyman for iOS currently has some other stubs in place
overriding the `console.*` functions. These should be removed for
release builds, so that we can use this pattern instead. I will try and
tackle this in a follow-up PR (I will build it on my mac so I can test
it).
A sample error report captured with this mechanism (no sourcemaps here
because this is a -local build):
https://sentry.io/organizations/keyman/issues/3401287467/events/c40fd2cebb7743cc8dfe72e0dd34bf65/?project=5983524
I am proposing we back-port this to 15.0-stable as we are missing a lot
of data in many of our error reports on Android.
