* 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!
