Add support for the Back key on Android

[dfaure]

Successfully tested with this code

forward-focus: my-key-handler;
my-key-handler := FocusScope {
    key-pressed(event) => {
        if (event.text == Key.Back) {
            root.close();
        }
        accept
    }
}

but also without (that was the hard part: letting Android terminate the activity on Back if it's not accepted by slint, which no longer happened after returning Some(...) in key_codes.rs)

[ogoffart]

Thanks, looks good to me.

[dfaure]

widgets_combobox_qt seems to fail reliably in CI after these changes, surprisingly.

However I don't manage to run that test locally:

 SLINT_TEST_FILTER=combo cargo test -p test-driver-rust --features build-time

   Compiling test-driver-rust v1.13.0 (/d/slint/tests/driver/rust)
error[E0433]: failed to resolve: could not find `NativeComboBox` in `sp`
 --> /d/slint/target/debug/build/test-driver-rust-510c5e5728f3f3d2/out/widgets_combobox_qt.rs:1:22529
  |
1 | ...* & InnerComboBox_root_4 :: FIELD_OFFSETS . r#native_6 } + sp :: r#NativeComboBox :: FIELD_OFFSETS . r#current_value) . apply_pin (_self) , ({ InnerComboBox_root_4 :: FIELD_OFFSETS . r#b...
  |                                                                     ^^^^^^^^^^^^^^^^ could not find `NativeComboBox` in `sp`

(and more similar errors)
i-slint-backend-qt builds just fine.

[ogoffart]

could not find NativeComboBox in sp

I have seen that before. I think it's a bug in the build script which somehow think Qt feature is active despite it is not (maybe because confused with other build)
Can add --features=slint/backend-qt to the cargo line

[tronical]

It’s weird how another PR I made earlier today passed nicely, but this one somehow triggers the QComboBox test (not build) failure.

There are warnings about threading that are also worrisome (not caused by this patch).

[ogoffart]

Wierd indeed. Maybe related to the change of run_change_handlers, although i can't see a difference.

[tronical]

Same here, I've been staring at the diff but can't see the difference. Somehow the defer! macro isn't producing the same behaviour.

[ogoffart]

Looks good to me.

[dfaure]

what's the next step? (this isn't like Qt, I can't merge myself)
@tronical needs to approve too?

[ogoffart]

Sorry, I wanted to merge yesterday but forgot.