Feature request: Support for Wayland's wlr-layer-shell protocol

[Keating950]

I would find it really helpful if winit provided a friendly interface for creating layer shells in Wayland, perhaps as an extension of WindowBuilder. So far, I haven't been able to find a solution for this in the Rust ecosystem other than by going to the relatively low-level SCTK. I'm imagining this feature could be gated off in one of the traits in winit::platform::unix module.

[maroider]

This was previously requested and subsequently rejected in #2142.

[Keating950]

Ah, that's a shame, but the reasoning makes sense.

[kchibisov]

We actually could support it given that android works similar to the wayland layer-shell stuff. So I'd keep that open, since we might add support for that.

[kchibisov]

Similar as in it destroys window from time to time. The problem is that keyboard input will work strangely and mouse input as well.

I'll keep it open to until ether someone or I will try to add it and we'll see how it goes. Though it might be not added in the end given how weird it is.

[TheOnlyMrCat]

sctk 0.16 doesn't provide any abstraction for layer shells, but there is an implementation on master. If I understand correctly, this means this feature is waiting on the release of wayland-rs 0.30, as well as the refactor that update would require within winit code.

[kchibisov]

Yeah, I'm waiting for wayland-rs for a long time already.

[yavko]

sctk 0.16 doesn't provide any abstraction for layer shells, but there is an implementation on master. If I understand correctly, this means this feature is waiting on the release of wayland-rs 0.30, as well as the refactor that update would require within winit code.

Once #2676 is merged, this won't be the case anymore, as sctk 0.17 is out, and it does provide the abstractions.

[Decodetalkers]

Now sctk 0.17 is merged.. Then what is going on? I cannot wait to use layershell

[yavko]

Now sctk 0.17 is merged.. Then what is going on? I cannot wait to use layershell

No one is working on it, that's what's happening. If you want to use it, then add it yourself. Though if I have time I'll try to learn how winit works and try impl it myself

[RegenJacob]

Would be great to get window::WindowLevel on wayland

[ids1024]

I don't think that's possible, really. The xdg_shell protocol used on Wayland for normal windows doesn't support anything like WindowLevel. To do that you need layer-shell, but the behavior is different from a normal window so it wouldn't be as simple as having an option to set the level of a window.

[nat-rix]

To do that you need layer-shell, but the behavior is different from a normal window so it wouldn't be as simple as having an option to set the level of a window.

Sorry, I don't understand what you mean by that. Is your point that as kchibisov pointed out "The problem is that keyboard input will work strangely and mouse input as well"?
Couldn't we do something like this on wlroots wayland:

fn with_window_level(self, level: WindowLevel) -> Self
    self.layer_shell.set_layer(match level {
        winit::window::WindowLevel::AlwaysOnBottom => sctk::shell::wlr_layer::Layer::Bottom,
        winit::window::WindowLevel::Normal => sctk::shell::wlr_layer::Layer::Top,
        winit::window::WindowLevel::AlwaysOnTop => sctk::shell::wlr_layer::Layer::Overlay,
    })
}

Does this break assumptions that winit or users would act on? If yes, couldn't we point out these quirks in a "Platform-specific" paragraph?

Also for notification windows and task/status bars window levels are basically an obligatory requirement combined with the ability to tell the desktop system some kind of anchor hint.
For the anchor I'm thinking of an API that looks something like this:

pub enum Anchor {
    TopLeft, TopCenter, TopRight,
    CenterLeft, Center, CenterRight,
    BottomLeft, BottomCenter, BottomRight,
}

impl WindowBuilder {
    /// Request that the window is positioned according to the specified anchor
    /// on the current Monitor and try to have a horizontal and vertical margin
    /// to the edges of the monitor.
    ///
    /// This is just a hint to the OS, and the system could ignore it.
    fn with_anchor_hint<S: Into<Size>>(self, anchor: Anchor, margin: S) -> Self;
}

• For wlroots wayland this could be done with set_anchor and set_margin with the layer-shell extension (I don't know if there is a corresponding alternative for Mutter)
• For X this could be done by strut_partial
• I don't have a clue about Windows or Mac but I'm sure there should be API for that
• On systems that support set_outer_position, we could maybe use that as a fallback

[kchibisov]

No, the main issue is that you have no focus, your window gets randomly destroyed, etc, etc. Like this issue was discussed numerous times and was postponed until 0.31.

[REALERvolker1]

It would be much MUCH better if it was implemented with missing features rather than waiting around until everything just works perfectly. Some of this stuff just won't work well in some compositors, but this protocol is essential for desktop programming with Iced and winit. Applications may not need these special extensions, but desktop components certainly do, and the only other viable alternative with layer-shell support is gtk3 (which I, for one, have several gripes with).

[REALERvolker1]

As for windows getting randomly destroyed and general instability, it would be much easier for the bugs to be resolved if more people used this feature. It would make us all more aware of bugs like these, and people can discuss and maybe fix them. The whole Wayland ecosystem is still pretty janky, but this may even be resolved by the compositors themselves or by wlroots as things mature.

[Decodetalkers]

We have made layershell binding for iced, and make something like winit, in https://github.com/waycrate/exwlshelleventloop. We also bind session-lock. Winit should better just handle xdg window. Yes.. I agree, so we made this project, and made platform plugin for iced. Maybe you can take a try.

And iced is planning to publish 0.13.. It may break many things. So if possible, if you are interested, please give us some help

[LucaCoduriV]

@Decodetalkers OMG MAN Thank you !! I was looking for this for so long !
I would be happy to help you if needed.

[The-Briel-Deal]

I've set up layer-shell from the compositor side and client side using wlroots and wayland-rs using wayland-client which we use as a dependency for wayland in winit.

Client implementation I made is in this repo https://github.com/The-Briel-Deal/gf-bar (which was just a small little status bar I made).

I haven't spent much time in the winit codebase but I might see if I can add an option in WindowAttributes to use layer shell as a POC here sometime this week.

I saw a few people saying that it wasn't possible because winit uses xdg-shell as it's role. That isn't a blocker at all though, you just need to request a different role during window creation and add the appropriate options in winit to set anchor, exclusive zone, margin, etc.

The one difficulty I see is if there is heavy usage of xdg-shell specific requests. But I'm hoping those can easily be disabled when you are using a layer-shell window.