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
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.
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.
Fixes: #13590
The previous code resulted in warnings showing up:
`(ibus-engine-keyman:4276): GLib-CRITICAL **: 14:31:16.030: g_hash_table_lookup: assertion 'hash_table != NULL' failed`.
This should work around the warning.
This is a workaround for missing 'und' language tag.
`(new Intl.Locale('und')).language` returns `undefined` in V8, as of 31
March 2025. This means we cannot rely on `Intl.Locale` to parse the
bcp47 string for us. The implemented workaround is to replace `und` with
a known-good language subtag, and then swap it back out in later
processing.
Also adds unit test and new warning messages for invalid language tags
that were exposed during testing of this.
Fixes: #13610
Fixes: #13620
Turns out there was actually a final-row pixel offset being applied for the OSK. I _believe_ this was something originally done for touch-oriented OSKs that ended up applied to all during 17.0's OSK refactoring efforts.
kmwosk.css does define layer-group padding above and below (1 px each) for touch keyboards already. Furthermore, things look fine when removing this extra 1px offset on the bottom from the last row. I think we're fine to just drop this minor offset and move on for now.
