This bypasses any need to modify KMW keyboard loading (say, via .fetch), though it does require a number of collateral changes to be made in order for CORS, etc to be satisfied.
Build-bot: skip build:ios
Pretty much just what the title says; it's been silently missing this whole time.
This doesn't fix iOS keyboard's display by itself, but it is a prerequisite for the full solution offered by #16136.
Build-bot: skip build:ios
Test-bot: skip
For Keyman for iOS, add the new `keyman-version` parameter to the
api.keyman.com/package-version call so that updates to packages that are
not supported on the current version of Keyman will not be offered. This
supports the scenario where an updated keyboard or lexical model depends
on a newer version of Keyman. Note that an older version of the keyboard
or lexical model package will not be offered (the user can still
download and install an older version manually, but generally, the
recommended solution is to upgrade Keyman; there would be significant
cost to add support for querying and installation of older version
keyboards on the server side, for limited benefit).
Also change order of handling for response so that error responses are
recognized even if non-error fields are present. (The current api
endpoint, before keymanapp/api.keyman.com#325 lands, can return `kmp`
and `version` fields even when an `error` field was present, and the iOS
code would see that as a valid response for upgrade, when it shouldn't.
The keymanapp/api.keyman.com#325 change ensures that the additional
fields are not set if there is an `error` field.)
Relates-to: keymanapp/api.keyman.com#325
- Also renamed `prefixed` and `withoutPrefix` functions to use the name
that was aliased on most cases: `toPrefixedKeyboardId` and
`toUnprefixedKeyboardId`.
- Renamed `ModelManager` class to `ModelCache` which was the name used
everywhere except in comments.
Part-of: #15292
Test-bot: skip
sentry-manager is used by Keyman Engine for Android and Keyman Engine
for iOS, but not directly by KeymanWeb, nor does it have any
dependencies on /web. So it does not make sense to keep it under /web.
es-bundling is used by sentry-manager and potentially other /common/web
tools in the future, so moving it under /common/tools makes it more
consistent in the future.
This is part of simplifying the web source tree; these changes do not
make significant build performance differences at this time.
Test-bot: skip
* Also renames resources/environment.sh to resources/build/mac/xcode-environment.inc.sh.
* Adds a few more exclusions to linux/scripts/dist.sh
Fixes: #14478
Test-bot: skip
Build-bot: build
Move mac-specific build scripts and functions into our established
patterns for scripts under resources/build:
* new mac/mac.inc.sh for mac-specific functions, from mac-utils.inc.sh,
utils.inc.sh, builder-basic.inc.sh
* move other mac-specific scripts into mac/
Relates-to: #14065
Build-bot: build
Test-bot: skip
Clarifies the confusing builder.inc.sh / build-utils.sh distinction by
giving the scripts more appropriate names. Most build scripts should use
builder-full.inc.sh; some helper scripts can use builder-basic.inc.sh.
Documented in resources/build/README.md.
Renames:
* resources/build/builder.inc.sh to resources/build/builder-full.inc.sh
* resources/build/build-utils.sh to resources/build/builder-basic.inc.sh
Other changes:
* Moves Android-specific functions out of builder-basic.inc.sh and into
android/build.sh.
* Renames functions in builder-basic.inc.sh
More functions may be moved from builder-basic.inc.sh into utils.inc.sh
or other scripts in the future.
Fixes: #14065
Build-bot: build all
Test-bot: skip
Adds documentation for various functions, removes unused functions (a
couple of simple, very lightly used functions were unDRYed; these could
go back the other way across all shell scripts if necessary). TODO items
noted for follow-up refactoring.
Fixes: #14275
Relates-to: #14269
Build-bot: build all
Test-bot: skip
Also adds minor documentation to new SentryManager.swift additions
Fixes: KEYMAN-IOS-MJ
This error was manually triggered to validate this PR's actual changes, given that the aim is to enhance error logging.
Previously the builder scripts defined a readonly `VERSION` environment
variable for the Keyman version. That caused problems when another
(external) script tried to define a `VERSION` variable. We encountered
this problem when trying to move the TC build steps of a configuration
into a single script (#13399) when we tried to source `~/.nvm/nvm.sh`.
This change uses a Keyman specific prefix for the version variables and
renames `VERSION` → `KEYMAN_VERSION` etc. Unfortunately these variables
are used in a lot of places, so this turned out to be a bit of a yak
shave.
Test-bot: skip
Warnings about known devices without predefined keyboard-scale map entries will be
limited to once per startup of the app and/or app-extension.
Test-bot: skip
See-also: #13769
Fixes: #12589Fixes: #13688
At some point, iOS seems to have enacted behavior that will cause a toolbar to go translucent/transparent in certain scenarios - such as when it would cover up the bottom of a fully-scrolled view. This has been triggering on our keyboard-search page, directly causing the behavior seen in #12589.
Reference: https://stackoverflow.com/a/71985231
It appears fixing this thoroughly _also_ addresses #13688, so... yay for "two birds, one stone"!
This PR updates the database that KeymanEngine uses to determine what size of keyboard to use for each device. This should ensure the default size for the keyboard matches the system keyboard's dimensions.
Fixes: #12590
If we're already showing the package-installer for a keyboard the user found via search... then we clearly downloaded it successfully. Why double-notify?
It turns out that #12590 itself was due to our usage of a TabBarController outside the prescribed safe use cases. We're actually fine most of the time... but it seems the tab area doesn't play nicely with a NavigationController toolbar, which is what displays download + update notifications. Rather than find a way to force that to work, it's simpler to just... not show the toolbar, **ever**, when the package installer is displayed.
This tweaks the recently-merged #13631, which accidentally introduced a bug in which _any_ downward swiping motion on the Settings view would always dismiss it, even should the user attempt to cancel dismissal.
Fixes: #13443
Slide-dismissal of the settings menu, and of the keyboard-height setting view in particular, should apply changes after dismissal... not only after backing out via navigation buttons.
Certain aspects of the iOS API didn't make it easy, though. After some searching, I found that "presentation controllers" and related can be leveraged to ensure we can detect Settings menu dismissal. With that detection in place, we can use the same method that's been working fine for us when backing out of Settings via button. This also ensures the keyboard will immediately display after dismissal, too!
