You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Widgets like LineEdit and SpinBox should select all of their text when they receive focus via keyboard. At least on Windows, this is common behavior.
In a shortcut (.lnk file) property dialog, e.g., you have multiple one-line text boxes. Initially, they are horizontally scrolled (no scrollbar, of course), so that the start of the text aligns with the left side of the text box. When you focus it, all text is selected, and (if it contains more text than can be displayed) the text box is horizontally scrolled, so that the end of the text aligns with the right side of the text box. When you then focus away from the text box, the horizontal scroll position stays the one that focusing established.
I wouldn't currently rule out that you could come up with a behavior regarding horizontal scrolling on focusing and unfocusing that'd be more desirable (probably taking into account, whether it was horizontally navigated between focusing and unfocusing). But the selection part helps with quick overwriting and is very useful in my opinion.
In the browser, I tested the text boxes on the following webpages as also implementing this behavior:
ogoffart
added
a:text
Text rendering, fonts, Text input (mS,bF)
and removed
a:widgets
Implementation of widgets (from std-widgets.slint) and their styles (mF,bS)
labels
Sep 16, 2024
A Qt application on linux does it, as well as firefox.
Reporter says it is like that on Windows.
I think it still make sense to implement that in TextInput rather than on the style and having it gated it with #[cfg(not(target_vendor = "apple"))].
Widgets like
LineEdit
andSpinBox
should select all of their text when they receive focus via keyboard. At least on Windows, this is common behavior.In a shortcut (.lnk file) property dialog, e.g., you have multiple one-line text boxes. Initially, they are horizontally scrolled (no scrollbar, of course), so that the start of the text aligns with the left side of the text box. When you focus it, all text is selected, and (if it contains more text than can be displayed) the text box is horizontally scrolled, so that the end of the text aligns with the right side of the text box. When you then focus away from the text box, the horizontal scroll position stays the one that focusing established.
I wouldn't currently rule out that you could come up with a behavior regarding horizontal scrolling on focusing and unfocusing that'd be more desirable (probably taking into account, whether it was horizontally navigated between focusing and unfocusing). But the selection part helps with quick overwriting and is very useful in my opinion.
In the browser, I tested the text boxes on the following webpages as also implementing this behavior:
The text was updated successfully, but these errors were encountered: