[Feature request] always on top window wayland

[BananaWorks07]

I am pretty sure always on top windows are supported on wayland through wlr-layer-shell, so I think it would be nice if it got supported in sdl2.
I can only think of one compositor (mutter) that doesn't support this feature, so it's probably worth implementing

[flibitijibibo]

I'm actually not 100% sure we can use this as an application library - the closest protocol I was able to find was wlr-layer-shell, and wlroots protocols are usually for the compositor. It does look like it has layers for topmost windows, but again I'm not sure we're supposed to be using this, unlike the protocols you can find in the core protocols repository.

[BananaWorks07]

I am pretty sure gtk-layer-shell uses it, and basically all compositors except mutter support wlr-layer-shell
edit: seems like I am right, this wlr protocol is implemented on basically every other compositor (that people actually use) except mutter

[BananaWorks07]

I was right, kde along with wlroots (ofc) support it
https://gitlab.freedesktop.org/wlroots/wlr-protocols
official description says that it also can be implemented in other compositors

[dos1]

Using layer-shell to implement always-on-top would be a huge abuse of the protocol and would be insanely broken when it comes to window positioning, resizing, placement on task bar and likely a lot of other things that don't instantly come to my mind. Please don't even consider this ;)

[BananaWorks07]

Using layer-shell to implement always-on-top would be a huge abuse of the protocol and would be insanely broken when it comes to window positioning, resizing, placement on task bar and likely a lot of other things that don't instantly come to my mind. Please don't even consider this ;)

could I ask why?
according to the wlroots documentation, "This interface should be suitable for the implementation of many desktop shell components, and a broad number of other applications that interact with the desktop."

[dos1]

layer-shell simply has no provisions to handle a regular application window like xdg-shell does, as that's not the use case it's supposed to accommodate at all. It's meant for system shell components and applications that augment them, such as desktop panels, wallpapers, lockscreens, notifications, system dialogs etc. While you could sure use layer-shell to make your surface appear on top of everything else, it would cease being an actual application window. It wouldn't appear on taskbar anymore (because system shell surfaces don't appear there), you wouldn't be able to initiate a move or resize actions (system shell surfaces generally don't do that), you would get different keyboard focus semantics (as system shell surfaces usually get special treatment there), your surface would become either centered on screen or anchored to some edge/corner (there are no other placement options provided by layer-shell and I don't know any implementation that allows user to move layer-surfaces around) and I'm likely missing a few side effects still. It's simply not suited for this purpose, by design.

Also, this isn't the case at the moment on most implementations, but layer-shell is generally meant to be a privileged protocol, so you can absolutely expect that in the future some compositors that support wlr-layer-shell won't expose it to regular applications, but will limit it to a set of privileged clients launched by compositor itself - otherwise it's a glaring security hole (you basically allow any random application to act as a lockscreen, steal focus arbitrarily, impersonate password dialogs etc).

[flibitijibibo]

The key phrase is "desktop shell components," which is what I was saying earlier - this is likely for things like picture-in-picture or taskbar elements rather than just app windows. It vaguely leaves the door open, but if this is something you want at the app level I would bring it up with the wayland-protocols repo.

[BananaWorks07]

The key phrase is "desktop shell components," which is what I was saying earlier - this is likely for things like picture-in-picture or taskbar elements rather than just app windows. It vaguely leaves the door open, but if this is something you want at the app level I would bring it up with the wayland-protocols repo.

The key phrase is "desktop shell components," which is what I was saying earlier - this is likely for things like picture-in-picture or taskbar elements rather than just app windows. It vaguely leaves the door open, but if this is something you want at the app level I would bring it up with the wayland-protocols repo.

there's an issue about picture in picture in that repo, so once someone makes a valid wayland protocol for it we could probably add it into SDL