Comments (5)
I think we need something like active_focus
the moment we introduce focus scopes. For consistency with has_focus
I suggest to call the property wants_focus
.
from slint.
I think we need something like active_focus the moment we introduce focus scopes. For consistency with has_focus I suggest to call the property wants_focus.
What's the use case for having these different properties. It must not be confusing and the semantic must be clear.
The use case i have in mind for focus property looks like this:
Foo {
// 1. Binding on focus to control the appearence if the object is focussed
color: focus ? red: blue;
on_something {
// 2. manually sets the focus to an item, eg, when entering a page or something.
some_item.focus = true;
}
// 3. When this window/tab/sub-region aquire the focus,
// this is the particular widget which aquire the focus
focus: true;
// The focus is set based on a condition: does that make sense?
focus: some_settings.sholuld_have_focus;
}
I think it only make sense to show the active focus. Or is there use case where we are interested on a different kind of focus in binding expression?
As for setting the focus, in my experience, one almost always want to set the active focus.
For the last use-case of setting the focus with focus:
, this is indeed a more local focus which is not the active focus. I guess we can make the compiler understand that when setting the focus in a .60 file is the default default focus on a region.
from slint.
I agree about those 3 use-cases (reading focus property, programmatically setting focus and expressing desire to receive focus when window/tab/sub-region acquires).
I think (1) and (2) are well covered with a single property, ideally called focus
indeed. That is simple and readable.
It's (3) that kind of ruins it :-) and I think it goes hand-in-hand with the question: How do you define these sub-regions? If, for example, we address (3) rather by means of declaring a "forwarding", then perhaps we can just stay with one "focus" property. I'd like that.
from slint.
A styled LineEdit
could perhaps serve as example:
LineEdit := Rectangle {
border_color: root.has_focus ? #556884 : #ffffff;
forward_focus: input;
// ...
GridLayout {
padding: 3lx;
input := TextInput {
...
}
}
}
Let's say we allow defining a forward_focus
property. That could perhaps also create a focus
alias to the forwarded element (property <bool> focus; focus <=> input.focus
in the above example`).
from slint.
The basic focus handling is implemented now, with TextInput
as the only element supporting keyboard events right now. has_focus
is the visible property for reading, someitem.focus()
can be called to explicitly focus an element and initial_focus: some_item;
can be used to point to an item that either shall receive the initial focus or by itself forwards using another initial_focus
binding.
from slint.
Related Issues (20)
- Float-to-string conversion while controlling decimal place count HOT 3
- Every Alt+Tab to window moves focus HOT 3
- quickstart/memory_tile: wrong @image-url for the Rust case HOT 2
- quickstart/polishing_the_tile: introduces the ui/appwindow.slint file without explanation (Rust case)
- panic when pressing Tab on a rolled-down ComboBox HOT 1
- Python: Expose Slint enums
- Issue with DatePickerPopup When using LineEdit Callback HOT 2
- Broken todo-mvc example HOT 1
- placeholder issue for images
- How to request permissions on Android with Rust ? HOT 1
- Using tokio::time::sleep() in a future passed to spawn_local seems to hang HOT 1
- MacOS Widget issues HOT 1
- Callback "edited" in TextEdit does not work
- TextInput.focus in PopupWindow causes crash in i-slint-compiler HOT 3
- Property in two-way binding cannot be set in C++ in special cases
- After window.hide() first and then window.show(), the content is not refreshed and the interaction is not feedback. HOT 3
- Failed to get "slint" as a dependency of package rog-control-center
- Cannot build on esp-idf framework with c++ HOT 3
- Windows: Use of popup menu created through raw Win32 API causes UI using Slint widgets to go "mute" HOT 1
- Nested @children attributes don't work
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from slint.