Focus doesn't go away when clicking outside TextInput

[ilmai]

I'm working on a DAW plugin with slint and in that context, it's absolutely essential that input focus is only kept while actually entering text. Otherwise for example pressing the spacebar won't toggle play/pause in the DAW when a plugin window is open.

Currently if you click on a TextInput, it will keep its input focus forever even if you click outside it. For reference, most of the regular (non-plugin) software I tested loses input focus when clicking outside a textbox, so this seems to be expected behavior even outside plugin context.

I'm currently using a workaround like this, that covers the entire root element, but it feels like a hack:

TouchArea {
    FocusScope {
        enabled: true;
    }
}

[hunger]

We need better programmatic control over the input focus. It is a currently entirely based on the item tree, which is not always what people need.

Many widgets accept keyboard focus and will do something on space or return presses (like toggle button state, open popups. etc.). So this is not limited to text edits. This is essential to have a keyboard navigable UI IMHO, which in turn is essential for some people with special input needs. So we can not just drop input focus in general

[tronical]

The acceptance criteria for this issue, as far as I can see it, is that the author of a DAW plugin can delegate focus back to the DAW when the user clicked outside of a text input in the Slint UI. This may require API in the platform API.

[ilmai]

Yep, I'm forwarding input focus requests to my windowing abstraction crate like this right now, and I would prefer something similar existed after the fix. The abstraction layer really needs to know if it should capture input or pass them to the host / parent window.

https://github.com/ilmai/plugin-things/blob/a731549b7e347176d52cafc134f2c05a36716e13/nih_plug_slint/src/window_adapter.rs#L321-L330

[tronical]

I think that perhaps the proposed API in https://github.com/slint-ui/slint/issues/3811 would help with this. @ilmai , what do you think? In your backend you'd then get a "Disable" InputMethodRequest.

[ilmai]

Yep that sounds good, as long as I get a Disable event when clicking outside a text field, it works for me!

[Enyium]

I find similar behavior quite strange: I have a LineEdit focused. When I then click a CheckBox or a Button, the LineEdit stays focused. Normally, GUIs switch the focus to the clicked widget.

On Windows, traditionally there's the concept of the focus rectangle (with dotted lines). But at some point in the evolution of Windows, it was implemented that mouse actions alone don't show the focus rectangle anymore, even though the widget is focused. The focus rectangle is shown, though, if you navigate via keyboard. In my tests I just did in various Windows dialogs with buttons, the focus is still visualized (when you click down and drag away on a button), but the additional focus rectangle is missing. Wouldn't that be a viable strategy: Subtle visual focus indication when using the mouse, and more prominent focus indication when using the keyboard?

[tronical]

I find similar behavior quite strange: I have a LineEdit focused. When I then click a CheckBox or a Button, the LineEdit stays focused. Normally, GUIs switch the focus to the clicked widget.

AFAICS that's because neither CheckBox nor Button claim the focus on click. The Button in the Fluent and Cupertino style support keyboard focus, when accessed via tab, but it doesn't take focus on click. The cosmic style as well as the Material style Button don't support keyboard focus at all.

Different styles mandate different behaviour, but at the moment none of the implement the behaviour you're looking for - AFAICS.