chore(web): improve error logging in predictive-text worker message validation
Previously logging an error resulted in two Sentry issues to be created. This change now combines the log message and the error into one call to `console.error`, thus resulting in only one Sentry issue being created.
Previously logging an error resulted in two Sentry issues to be created.
This change now combines the log message and the error into one call to
`console.error`, thus resulting in only one Sentry issue being created.
fix(linux): allow unhandled keys to pass through to compliant apps
This change fixes a bug introduced in #13372. Before that engine.c determined if keys are handled or not. For keys that we didn't handle we returned FALSE. However, that didn't allow the Core to adjust the context where necessary, so #13372 moved that to Core. However, this caused ibus_keyman_engine_process_key_event to return TRUE even if we didn't handle the key. Instead we called ibus_engine_forward_key_event with the non-handled key. This worked in most applications, but not in the Text Editor.
This change now does no longer call ibus_engine_forward_key_event for compliant apps but instead returns FALSE from ibus_keyman_engine_process_key_event for unhandled keys, allowing the app to see and act on the key event.
An 'unhandled' key here is a key that doesn't match a rule in the keyboard and isn't a character key. Core returns a QIT_EMIT_KEYSTROKE action for that key.
Fixes: #13590
# Keyman Conventional Commit suggestions:
#
# - Link to a Sentry issue with git trailer:
# Fixes: _MODULE_-_ID_
# - Give credit to co-authors:
# Co-authored-by: _Name_ <_email_>
# - Use imperative, present tense ('attach' not 'attaches', 'attached' etc)
# - Don't include a period at the end of the title
# - Always include a blank line before trailers
# - More: https://github.com/keymanapp/keyman/wiki/Pull-Request-and-Commit-workflow-notes
Addresses a PR comment by mcdurdin on #13597 (at https://github.com/keymanapp/keyman/pull/13597#discussion_r2023971170) in regard to the motivation for gesture input serialization.
> I just don't understand how the problem described here can arise -- unless we are introducing deferral with promises -- but even then, if we consistently defer every incoming event with a promise, then the order would still be automatically enforced.
In particular, this aims to clarify how the macrotask queue gets involved and can interfere with the ordering of promises.
Follows on from the similar changes to `Keyboard` fields in #13600. This
deprecates the `RTL` and `Name` fields. `RTL` was never used. `Name` was
written but never presented to end users, so effectively irrelevant.
`Name` also was present in `File.Description` (already deprecated) for
the corresponding model.js _and_ `Info.Name`, so doubly redundant.
Also updates the schema documentation to mark the deprecated fields.
Relates-to: #13600
refactor(linux): remove warning if no custom keyboards exist
If the dconf setting for custom keyboards doesn't exist, i.e. we never saved custom keyboards before, the previous code resulted in a warning showing up: `(ibus-engine-keyman:4276): GLib-CRITICAL **: 14:31:16.030: g_hash_table_lookup: assertion 'hash_table != NULL' failed`.
This PR adds a null check before trying to access the custom keyboards hash table and thus removes the warning.
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!
