Feature request: callback on text input focused/unfocused

[eupn]

Hello,

On our embedded platform we have a virtual keyboard running as a background app that can popup whenever an app needs a text input. By looking at the software keyboard example, it's clear that the software keyboard is implemented as a component that gets showed conditionally depending on the TextInputInterface.text-input-focused property.

• Is there a way to react (make a callback) to the TextInputInterface.text-input-focused property value being changed?
• Is it possible to extend the Slint to call a native (Rust) function every time a text input element got focused and unfocused?

This way we'll be able to use our system's API to show/hide the popup keyboard, which is a separately running app.

Best,
eupn

[FloVanGH]

Hello,

unfortunately there is callback right now for the TextInputInterface.text-input-focused property. Is was thinking what it could looks like:

window.global::<TextInputInterface>.on_text_input_focus_changed(|| {
    // call my logic 
});

@ogoffart what do you think?

[ogoffart]

I think such callback in TextInputInterface would make a lot of sense.
i'm wondering if it should have arguments or not. (or if there should be two callback, one when it gets focus and one when it loses it) and perhaps return if the "default" on-screen keyboard should open or not.

[tronical]

I agree. I'm leaning towards a callback that takes an enum as a parameter. That way we can add more variants later with "ease". Same for the return value perhaps.

[ogoffart]

Out of curiosity, what backed are you using?
We do send event in the Qt and winit backend for the IME things, and it should then propagated to the platform, maybe there is a way to hook into that?

[eupn]

Out of curiosity, what backed are you using? We do send event in the Qt and winit backend for the IME things, and it should then propagated to the platform, maybe there is a way to hook into that?

Hi @ogoffart, it’s an embedded platform and we use a software backend for now. It’s a `MinimalSoftwareWindow` IIRC. And both `input_method_request` and `handle_focus_change` are hidden behind a private trait `WindowAdapterInternal` so we can't reimplement them. The best option would be to have a callback in `TextInputInterface` component proposed by @FloVanGH and it might require an internal change of hooking it up from within the `WindowAdapterInternal` that's available from inside `slint`.

[ogoffart]

The reason I asked is because I think it might be the main use case that it is used by the platform implementers. I think the callback should be exposed in the WindowAdapter for the platform implementer. It is not part of our public API right now, but it should be polished and put there.

But then there should also be API in MinimalSoftwareWindow, i guess since that it what you are using.
Otherwise you can query the value of text-input-focused in your event loop.

[eupn]

Polling for the text-input-focused change in the event loop sounds like a decent solution for now before (and if) #3796 is merged.