- Create and sign source package
- Upload to mentors.debian.net
- Create (and optionally push) commit with updated changelog file
based on stable branch
- Create (and optionally push) commit with updated changelog file
based on master branch
The name json.hpp conflicts with the JSON for Modern C++ library that
is also used by Developer. Renames json.hpp and json.cpp to jsonpp.hpp
and jsonpp.cpp aka "JSON Pretty Printer".
This change updates the changelog to keep it in sync with Debian
where PR #6966 got applied to the current stable version.
(cherry picked from commit c45dea856d)
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.
Fixes#6981.
Longpress menus were being triggered on any detected movement on keys on
Android. This would cause rapid typing to periodically fail as the user
would make a single-pixel movement while typing, which would then block
subsequent key events.
This issue was introduced in #6637, which resolved a somewhat related
problem with sticky longpress menus.
The fix is in three parts:
1. Remove the touch movement detection which caused the primary problem
2. Address some logic issues around visibility of `subkeysWindow`
3. Introduce a new 'scroll' gesture handler which detects a negative-y
movement above a 5px threshold, to open the longpress menu.
The 5px threshold is the minimum default used by Keyman Engine for Web.
However, it may not be ideal, and we should consider moving to using the
0.25 x row height value that Keyman Engine for Web uses in a future
update. However, I do not consider this to be a reason to block this
fix, as it would require significant extra engineering.
This will refresh the list of installed keyboards even when we
install a keyboard from a command line tool, or from a second
km-config instance.
Closes#6785.
tidied up +removed unnecessary files
checked contents of files+included a few new functions needed for myVersion
changed datatypes in CheckForDuplicates
tidy up more paths
CheckFileConsistency: not able to fully adapt for use of char16_t on non windows p.
-> used char16_t + commented out some AddWarning().
