Skip to content
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

Layers #30

Closed
hecrj opened this issue Oct 23, 2019 · 11 comments
Closed

Layers #30

hecrj opened this issue Oct 23, 2019 · 11 comments
Labels
feature New feature or request help wanted Extra attention is needed
Milestone

Comments

@hecrj
Copy link
Member

hecrj commented Oct 23, 2019

Currently, Iced assumes widgets cannot be laid out on top of each other. We should implement support for multiple layers of widgets.

This is a necessary feature to implement many kind of interactables, like dropdown menus, select fields, etc.

iced_native will need to group widgets to perform layouting and process some events first for widgets positioned on top.

iced_wgpu will also need to process the scene graph and sort draw calls based on the different layers.

@hecrj hecrj added the feature New feature or request label Oct 23, 2019
@hecrj hecrj added this to the 0.2.0 milestone Oct 23, 2019
@hecrj hecrj added the help wanted Extra attention is needed label Oct 23, 2019
@manokara
Copy link

manokara commented Nov 8, 2019

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?

@hecrj
Copy link
Member Author

hecrj commented Nov 8, 2019

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.

@frapa
Copy link
Contributor

frapa commented Apr 10, 2020

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.

Selectbox
image

Menu
image

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...

@krupitskas
Copy link

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?

@dhardy
Copy link

dhardy commented Jul 9, 2020

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).

@AshfordN
Copy link

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.

@hecrj hecrj modified the milestones: 0.4.0, 0.5.0 Apr 12, 2022
@genusistimelord
Copy link

genusistimelord commented May 31, 2022

@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

  1. Need a connection point that can be added at view creation.
  2. Decide if you want a slower list or a Vec .
  3. Need to keep track of the current top most object and must place its children as the top most in the rendering list.
  4. 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.

@dhardy
Copy link

dhardy commented Jun 1, 2022

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.

@hecrj hecrj modified the milestones: 0.5.0, 0.6.0 Nov 9, 2022
@hecrj hecrj modified the milestones: 0.6.0, 0.7.0 Dec 7, 2022
@hecrj hecrj modified the milestones: 0.7.0, 0.8.0 Jan 14, 2023
@hecrj hecrj modified the milestones: 0.8.0, 0.9.0 Feb 18, 2023
@hecrj hecrj modified the milestones: 0.9.0, 0.10.0 Apr 13, 2023
@hecrj hecrj modified the milestones: 0.10.0, 0.11.0 Jul 28, 2023
@Remmirad
Copy link

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
  • 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).

@genusistimelord
Copy link

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.

@hecrj
Copy link
Member Author

hecrj commented Feb 7, 2024

Solved by #1719.

@hecrj hecrj closed this as completed Feb 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

8 participants