zwlr_layer_shell_v1 supported #1765
Replies: 4 comments 2 replies
-
What is your use case? We would need support for that in the winit crate that is handling our wayland interaction. |
Beta Was this translation helpful? Give feedback.
-
Layer Shell is a wayland protocol that allows an application to occupy an exclusive area on the screen (overlay, anchored to screen anchors etc.). This is highly useful for building shell components like bars, panels, login screens, etc. Protocol description Demo of the protocol by Drew DeVault: https://www.youtube.com/watch?v=VuRXHJu5Kmg Similar GTK project, that adds layer shell to gtk3 An example panel project that uses gtk-layer-shell |
Beta Was this translation helpful? Give feedback.
-
I think the concrete way of anchoring and layering surfaces is an implementation detail. As such, I'm not sure Slint can provide any functionality regarding the concrete protocol. However, Slint can and should provide access to the wayland display and the wayland surface for a given window, so that applications can connect that to their code to send/receive wlr specific messages to/from the compositor. As such, I think we should provide access to the raw-window-handle's RawDisplayHandle and RawWindowHandle. |
Beta Was this translation helpful? Give feedback.
-
The earlier comments sound super good! Below are some of my thoughts as a first timer going through the code base: I think this kind of hacks could work to get all the requirements for layer shell to one place
All of these options sound nice on the outside but there are quite many gotchas. Let's think about a case where someone wants to implement for example a shell component using zwlr_layer_shell_v1.
There are some concerns about that, the first being that a window needs to be shown from Slints point of view first before any Wayland connections exist. For applications such as notification daemons, the window should only be shown when reacting to for example an IPC call. This window "flashing" could maybe be worked around by setting the window to be not visible in the winit builder (however their documentation seems to suggest that set_visible is not working for wayland) Frankly the only way I see these nieche cases to be able to be addressed is to have the So bringing my miscalleneous thoughts together:
TBH this looks like being pretty close to the MinimalSoftwareWindow solutions but with ability to replace that by something that can be given |
Beta Was this translation helpful? Give feedback.
-
This protocol is useful when on wayland, can make a float window on screen. Will you support it in slint in the feature release?
Beta Was this translation helpful? Give feedback.
All reactions