The response is the same as for other PRs, not unless backend split is done, which I hope should be soon.

Well, it seems completely make sense to me, is there any site where they are discussing this topic? I will leave the PR open for now and keep it updated with respect to the main winit branch.

Everything you need is present on github issues here and opened PRs. You can subscribe to #3433 .

Perfect, thank you, I also joined the matrix server that you have in the README, I will be in contact to help you with whatever you need 🦀

Are you still planning to update the PR? With the new splitting up into crates, is the expectation that all this will move to the winit-wayland crate?

@vikigenius yep, a little while ago I saw that they already updated the modules, but this week I didn't have time to update the PR but I plan to do it as soon as I'm free

Hey, just to notify, I am going to continue this in another PR, the restructuring made some disastrous changes in what I had, so I prefer to have a clean and new PR, I hope the manteiners agree

I'd add that after we've split things, you can implement layer-shell by ripping of xdg shell and its related stuff (e.g. winit-layer-shell). And also, it doesn't have to be here. While I still want it to be here, winit users now would likely accept winit-core rather than winit crate itself, so you won't need to deal with e.g. upstream review where we figure things and just use layer shell.

Hey, I've been going through the restructure and recovering some past changes I've put together a base, it doesn't compile yet, but I'll be making adjustments and integrating an example to be able to do local testing, I'll just say that the PR has come back to life

Though, just thinking that may be direct integrating into winit-wayland at this stage is also fine. You just don't have to expose it through winit-core. And you can also define a trait for new layer-shell events directly inside the winit-wayland.

Thank you very much for doing this,

after reviewing the file. it seems like there are bit too much difference between layer shell and xdg window. It might be reasonable to split it into two separate crate (or a feature gated module). Specifically I think we need a separate "window" state and Window.

I understand that it can be tricky to maintain parity between the two, but the difference isn’t that significant, and I think the solution we have now is quite prudent, because it preserves a single API from the outside while handling the differences internally. If we split it into smaller crates, it will be much harder to maintain, and you’ll end up with two completely different APIs, making the code and external usage much more verbose. So far, there are only a few things that Wayland doesn’t support due to the protocol, but I don’t think they’re enough to warrant splitting it up.

My biggest concern with this release is that many of us need an official solution from Winit for LayerShell support in Wayland, so I hope we’ll see progress sooner rather than later.

Regardless of the decision, I’d like to be kept in the loop, and if you’d like me to implement whatever decision you make, I’d be happy to do so. For now, I’ll try to keep this PR up to date 🫡

Hello! What's the state of this PR? I'm waiting for this to merge so layershell support could potentially be added directly to iced.

The current implementation adds layershell support into the window itself - is this a good idea? Layershells are not designed to be used as xdg surfaces, as per the protocol. Note, that you should not use it to move the window at will or get its position either, as suggested in the initial PR comment.

In my opinion ideally we should think of wayland as mainly wl_surface with a role - be it xdg toplevel or a layer_shell. Maybe rename the Window into WlSurface on a second look, Window works fine too I think, doesn't really matter. I will have to look at the architecture more thoroughly. This approach also allows implementing session_lock later on with minimal architectural changes.

I could also help fixing the layer_surface destruction bug.

Alright, I've looked into the bug and merged upstream into the branch (will push to my fork soon). As you know, layershells get destroyed when an output disconnects. The problem is with who is responsible for that. It seems like winit does not expose output events.

What this means is that we need to keep track of what layershells were on which output, which is not that hard to do. The problem with that is flexibility - let's say I'm developing a wayland bar. I'd much rather manage my outputs myself (and that's what people do). It doesn't really make sense to be any other way - if your outputs are managed by winit the application can't really know what's happening, so I think the perfect solution would be exposing the output events to the user. In case that is not possible, the shell state saving behavior should be opt-in.

So, what should the design choice be?

What's the state of this PR?

Wayland maintainer (Kirill) is a bit busy last I heard, but will hopefully maybe get more time soon.

Wayland maintainer (Kirill) is a bit busy last I heard, but will hopefully maybe get more time soon.

I see. Well, in the meantime I think we should figure out an optimal design for the layershell and output management as I've described in my previous comment.

Hey, I just updated the PR to reflect the latest changes on the master branch.

Well, in the meantime I think we should figure out an optimal design for the layershell and output management as I've described in my previous comment.

I’d really like to move forward with this PR so it can be merged. We can easily discuss your comments. I’d also like to make sure the API is solid so that, in the future, it’ll be easy to extend the capabilities of the layer_shell, as you mentioned with session_lock. So I'm really open to any suggestions, review, comments or disscussion (probably on the Matrix channel)

Can you send the matrix room? Thanks. Joined.