Comments (11)
I would like to add my 2 cents. In other GUI libraries like GTK under X11, such overlays are actually separate windows, and can therefore extend outside the actual application window.
In my opinion, this is very useful for dropdowns and menus. I collected a couple of screenshots to illustrate my point.
In such cases or in cases of very small windows, it looks like it would be desirable to have a similar effect in Iced, too. I'm absolutely not sure how difficult something like that is to achieve...
from iced.
I do not have a particular approach in mind yet. There is definitely an interesting amount of exploration ahead of us here.
I do know using something like absolute indices (like z-index
in CSS) can be quite painful and does not compose at all.
A relative Layer
widget sounds like a good idea to me, as I think it should compose no matter where you decide to nest it. elm-ui
follows a similar approach and the author gave a great talk in elm-conf with many interesting ideas. I recommend watching it for inspiration!
Given a combobox for example, would it be best for the choice list to be part of the drawing code and the widget set to be on top (and ComboBox::new actually returns Layer(ComboBox {...}, Depth::Above) or the choice list be a separate widget, attached to the ComboBox's layout? Or maybe there's a better approach?
I think layers (or at least event layers) will need to exist as a first-class concept in iced_native
. As of now, they cannot simply be another widget because the runtime needs to be aware of them. In other words, update
needs to be aware that layers on top, although potentially nested deeply in the widget tree, should capture mouse events.
I am not yet sure about how we will end up implementing this. I do have the feeling that the different methods in the Widget
trait are inherently coupled (node
defines layout, which in turn affects on_event
, draw
, and hash_layout
). Layers will make this coupling even more apparent.
I think the problem is telling us something here: we should define layout, update, and draw in a unified, declarative way. The runtime will then figure out how to process events and draw widgets. How could this API look like? I am not sure yet! π
This is where we should explore! I think the way iced_web
works makes everything very composable and easy to extend.
from iced.
Solved by #1719.
from iced.
How would the depth of the widgets be determined? Maybe with something like this?
enum Depth {
Above,
Below,
Topmost,
}
fn view(&mut self) -> Element<Message> {
// ...
Layer(SomeWidget::new(), Depth::Above)
// ...
}
Then the current depth would have to be kept in the layouting state. Given a combobox for example, would it be best for the choice list to be part of the drawing code and the widget set to be on top (and ComboBox::new
actually returns Layer(ComboBox {...}, Depth::Above
) or the choice list be a separate widget, attached to the ComboBox's layout? Or maybe there's a better approach?
from iced.
Isn't it better to achieve single instance window widget support @hecrj ?
After we can improve it to have such functionality like gimp has.
If such, in our app windows are crucial and we really want to use iced, so we can definetely contribute, but can you guide and write your general ideas about layers first naive implementaion, so I can submit draft for pull request?
from iced.
Separate windows would be the ideal way to go, but aren't really supported by winit yet (rust-windowing/winit#403), and even if it were I don't know if it would be portable to all platforms (e.g. Android).
FYI, for KAS I solved the event handling via specific support for "pop-ups" (still a bit hacky, but required to support closing menus when clicking under them and things like accelerator key bindings on the menus). For drawing it uses the depth buffer with some specific offsets (not the only option, but otherwise you'd need indirect drawing for each layer I believe).
from iced.
This is a necessary feature to implement many kind of interactables, like dropdown menus, select fields, etc.
@hecrj isn't this already achieved through overlays? Could you explain the difference between a overlays and what you're suggesting? I'm a bit new to Iced, and I don't have a lot of experience with the API as yet.
from iced.
@AshfordN overlays do somewhat work but the issue become when you have a lot of overlays which ones should be rendered above the others. So in this case a lot of GUI libraries even Microsoft's UI stuff uses Z List rendering/ordering. All this means is they have a Arc connection point to a list and the list is just used for the rendering order. A list works the best for this method since you can Add children quickly above it and additions don't normally matter as much. To use a faster method for rendering like a Array/Vec you would need to pull in the top most first and then everything else starting from its children and then back in reverse. so the children or top most object is last/first in the array. and moving them around should be OK to do as well. In C we would use memmove() but if you use Vec or an actual list should be good enough since both support those methods safely.
This would be
- Need a connection point that can be added at view creation.
- Decide if you want a slower list or a Vec .
- Need to keep track of the current top most object and must place its children as the top most in the rendering list.
- Make it so the Top most is the last rendered, based on how you decide to order it in the list.
@dhardy: separate windows would need to be an enabled feature and would also require a separate list of widgets per window. this also means a different sandbox etc per window. for it to work optimally. I did some work a while back with GLFW and multiple window support is nice but they function as their own individual programs just with shared memory.
from iced.
Regarding child windows, there is now this PR for winit (X11 only): rust-windowing/winit#2246
As @genusistimelord notes, having an application spawn multiple windows isn't exactly hard (KAS has had a "synchronised counter" example since very early on), but tying together event handling across windows for uses like menus is harder.
from iced.
Is there any kind of requirement list?
What I could gather so far from the above discussions, other comments and some own ideas is that the layering system should allow:
- Nested widgets (e.g. drop list) need to be able to display things above others even when higher in the widget tree
- Layering should be able to be nested (like some subspace in the window where things are layered but don't overlap with the outside?)
- Items on top of other items should get events first
- There are "overlays" that belong to a widget like (drop list) and there are overlays that are independent like modals
- This also means the layering system has to be accessible from inside a widget and probably also for a user in
view
- This also means the layering system has to be accessible from inside a widget and probably also for a user in
- The ordering should be done rather relative instead of absolute (e.g. z-index, except for things like
topmost
) because users are mostly concerned with "I want this thing to go above/below that" (Relative to "that") - The layers probably need to support some kind of focus concept. When many dialogs stack the focused one should be on top (Iced would need a concept of focus for this, but one could try to keep it in mind)
- This also implies that there is some kind of "baselayer" that is never on top of e.g. modals
- There will be cases where the user wants to decide where things go but in many cases it should just work (you don't want to specify where the list of a drop-down goes or how to handle it)
These are just some ideas I gathered and a complete list would be helpful / would need to be discussed (maybe already exists and I just missed it).
from iced.
Currently hector has kindof made layering possible with the ability to create more layering structs which is helpful for fixing the overlay issues.
Event wise the Zlist/Focus would generally be the fastest method for this as you would mostly check if it is over the focused item first. if not then detect what new thing it is over/handling and attempt to delegate the events upon those. Some older GUI went as far as building a Image map and using it to determine where the event occurred and what Colored index existed there.
from iced.
Related Issues (20)
- TextInput value overflow with tiny-skia backend
- web-sys dependecy resolution HOT 1
- image ferris cannot be loaded in tour example under wasm target
- MouseArea does not report mouse wheel events.
- Nix shell expression out of date in `DEPENDENCIES.md` HOT 1
- Nested scrollable behaviour
- command::Action is used in the public API but is not re-exported
- readme out of date
- error: WaylandError(Connection(NoWaylandLib)) when using nixos and shell.nix from DEPENDECIES.md HOT 1
- How can perform async task in component?
- How can perform async task in component?
- Layout issues when resizing window HOT 5
- Miscompilation issue / problem with perf - addr2line: could not read first record
- button::Appearance has both `shadow` and `shadow_offset` properties HOT 1
- Crash when resizing window with scrollable
- The buttons contain different single English characters, yet their sizes vary. HOT 2
- Iced does not properly render Canvas with webgl backend HOT 2
- App resolution is too high and does not follow system settings HOT 3
- win10η³»η»θΏθ‘,η¨εΊιεΊδΌε΄©ζΊ;Windows10,program will crash when it exits HOT 1
- Integration example panics with wgpu validation error on macOS HOT 1
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 iced.