FocusScope: add consume-focus-click property#12045
Open
Eyalm321 wants to merge 2 commits into
Open
Conversation
When a FocusScope does not yet have focus, the pointer press that gives
it focus via focus-on-click is consumed, so it never reaches other
pointer handlers under the cursor ("click once to focus, click again to
act"). Once the scope has focus, the same press propagates, so only the
focus-delivering press is special.
Add an opt-in boolean property consume-focus-click (default true,
preserving the current behavior). When false, the press still transfers
the focus but returns EventIgnored so it continues to elements behind
the scope, e.g. a sibling TouchArea.
The default stays consuming so the nested-scope behavior from slint-ui#2530 is
unchanged.
Fixes slint-ui#12044
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #12044
When a
FocusScopedoes not yet have focus, the pointer press that gives it focus viafocus-on-clickis consumed (EventAccepted), so it never reaches other pointer handlers under the cursor — the classic "click once to focus, click again to act" behavior. Once the scope has focus, the same press propagates (EventIgnored), so only the focus-delivering press is special.This adds an opt-in boolean property
consume-focus-click(defaulttrue, preserving the current behavior) following the two existing booleansfocus-on-click/focus-on-tab-navigation(per the API-review preference for booleans over a policy enum in #9263). When set tofalse,FocusScope::input_eventstill transfers the focus on press but returnsEventIgnored, letting the press continue to elements behind the scope (e.g. a siblingTouchArea).The default stays consuming so the nested-scope behavior from #2530 (
tests/cases/focus/event_propagation_3.slint) is unchanged; the docs note that opting in allows an enclosing defaultFocusScopeto take the focus instead.Two points I'd welcome guidance on:
consume-focus-clickdoesn't follow thefocus-on-*prefix of its siblings; happy to rename (e.g. if you'd rather frame it positively).FocusScopewill take the focus from the propagated press — documented). A deeper alternative would be dispatcher-level tracking of "focus already claimed during this press" (or a dedicatedInputEventResultvariant) so ancestors skip their grab without consuming; that would even make pass-through safe by default, but it's a bigger change tointernal/core/input.rs. Happy to rework in that direction if preferred.Includes:
internal/core/items/input_items.rsandinternal/compiler/builtins.slint(docs inline)tests/cases/focus/consume_focus_click.slint(rust/cpp/js) covering both default and opt-in behavior🤖 Generated with Claude Code