Skip to content

FocusScope: Distinguish between keyboard focus and click focus #8387

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tracked by #1494
ubruhin opened this issue May 6, 2025 · 2 comments · Fixed by #8569
Closed
Tracked by #1494

FocusScope: Distinguish between keyboard focus and click focus #8387

ubruhin opened this issue May 6, 2025 · 2 comments · Fixed by #8569
Labels
a:language-slint Compiler for the .slint language (mO,bF) need triaging Issue that the owner of the area still need to triage

Comments

@ubruhin
Copy link
Contributor

ubruhin commented May 6, 2025

Feature Description

Currently the FocusScope can either be enabled, which makes it focusable by tabulator key or mouse click, or disabled, which does not make it focusable at all. However, in some cases one wants to make a component focusable only by keyboard or only by mouse click. In Qt this can be controlled with the Qt::FocusPolicy on any widget. I think a property like that would make sense on the FocusScope.

In addition, when an element gets focus, in some cases we need to know the reason why it got the focus. A basic example is a text input which selects the whole text when it gets the focus by keyboard, but not when it is clicked.

Currently we can only react on the has-focus property:

component MySpecialTextEdit {
    TextInput {
        changed has-focus => {
            if self.has-focus {
                self.select-all();  // Should be done only by keyboard focus, not by mouse click!
            }
        }
    }
}

I think FocusScope should have a callback like focused(reason: FocusReason) so we can decide on the passed focus reason what we want to do. Possibly the focus() function should also get a parameter to pass the reason, but it may not be needed as tab-focus and click-focus is handled internally in FocusScope.

Interestingly in Qt the Qt::FocusReason contains even several more focus reasons. It may make sense to consider carefully which of them make sense for Slint too.

Btw, a focus-lost() callback might be useful too. Actually there's already a focus-changed-event() but it does not seem to have any advantage over a changed has-focus => {} handler, it does not even tell if it was a focus-in or focus-out 🤔

Product Impact

No response

@ubruhin ubruhin added enhancement New feature or request need triaging Issue that the owner of the area still need to triage labels May 6, 2025
@ogoffart
Copy link
Member

ogoffart commented May 7, 2025

I think it make sense. There is already an issue regarding the focus policy: #3503

I think FocusScope should have a callback like focused(reason: FocusReason) so we can decide on the passed focus reason what we want to do.

Makes sense as well, but I'm curious what is your usecase for this.

@ubruhin
Copy link
Contributor Author

ubruhin commented May 7, 2025

Makes sense as well, but I'm curious what is your usecase for this.

At the moment I just want to make my custom text edit, based on TextInput, select its text when focused by keyboard. But actually this is not directly an issue of FocusScope but of TextInput, which should have this behavior out of the box.

It was just an idea to consider, but for me the FocusPolicy feature is much more important.

@ogoffart ogoffart added a:language-slint Compiler for the .slint language (mO,bF) need triaging Issue that the owner of the area still need to triage and removed enhancement New feature or request need triaging Issue that the owner of the area still need to triage labels May 7, 2025
ogoffart pushed a commit that referenced this issue May 27, 2025
…ocus for TextInput (#8523)

Closes #5992

Adds the enum FocusEventReason and makes it an argument for FocusEvent. This reason could eventually be exposed in Slint to solve #8387.

Using the focus reason tracking, I also added a select all on keyboard focus for TextInputs (except on macOS), which should close #5992.

ChangeLog: TextInput selects its content when focused with the keyboard on Windows and Linux
codeshaunted added a commit to codeshaunted/slint that referenced this issue May 27, 2025
codeshaunted added a commit to codeshaunted/slint that referenced this issue May 28, 2025
codeshaunted added a commit to codeshaunted/slint that referenced this issue May 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:language-slint Compiler for the .slint language (mO,bF) need triaging Issue that the owner of the area still need to triage
Projects
None yet
2 participants