Popups on Wayland & rendering to a separate surface?

[ngortheone]

Popups on Wayland are rendered to a separate surface, which allows a popup to extend beyond the area of the main window. This is useful for creating applications like docks/panels - think of classic Windows "Start" button that shows a popup menu with installed programs. (and any other application that has small height)

A demonstration of popups on wayland:
wayland-popup.webm

Dear imgui draws everything to the same surface. Is it possible to do draw a popup to a separate surface (given that backend provides it)? How difficult is going to be hack such functionality? I'd love to dive into the code, please give me some pointers if possible

Thanks!

[ocornut]

The Multi-viewports feature is already creating new surfaces, but AFAIK wayland gives no way for apps to position windows or read their position so it's all broken there.

Generally speaking multi-viewports don't work well on Linux and X already (#2117) (partly because I am not using those systems). I suspect even for X we need to give hints to window managers so e.g. tooltips and popups are not re-positioned nilly-willy by window managers. There's a bunch of work to do both for X and for Wayland on this but it's not going to be simple. I cannot "give some pointers", this is going to be really involved and focused work. Right now given the wording of the question you did not seem aware that multi-viewports was a thing so I'll let you do some research there and try the branch and see how/if things can be fixed for Wayland.

[ngortheone]

@ocornut wayland has ways of positioning popups, so it that specific usecase it should work.

[ocornut]

I assumed it would have a way to do, similarly to
#2117 (comment)

Given the complexity of that code (we haven't had meaningful Linux related fixes) I think the best direction would be:

• Have people gather all the infos and proof of concepts for what we need and what the restrictions are.
• That should include ways to implement platform-specific workarounds when using SDL or GLFW backends.
• That should cover X and Wayland.
• Test and publish all those infos and proof-of-concepts without attempting to fix the existing code/branch: that itself may be too distracting.
• We can then decide if I can use that info to fix existing code/branch or if it'll wait and weight in the design for a V2 of viewports (which is desirable at this point).
• Rokups general suggestion was that we should give-in more to the WM, use WM facilities to move/resize windows (may include forwarding events on our widgets to WM to let them know "this is aiming to move a window"), and provide hints when we can but not expect them to be full-filled.

Since I am expecting to rewrite viewports down the line, this gathering of infos would be quite desirable to happen beforehand.

[scorpion-26]

The Multi-viewports feature is already creating new surfaces, but AFAIK wayland gives no way for apps to position windows or read their position so it's all broken there.

@ocornut wayland has ways of positioning popups, so it that specific usecase it should work.

Multi-Viewport functionality can't be properly implemented with xdg_popup (The Wayland popup object), since they require to be closed from top to bottom (From the spec: "If this xdg_popup is not the "topmost" popup, a protocol error will be sent."). Since the multi-viewport windows should behave just like normal windows, that is a major restriction.

Another wayland object, which can be freely moved (but not resized!) by the client is wl_subsurface (Spec: https://wayland.app/protocols/wayland#wl_subsurface). I haven't tested yet if they work in the same way as secondary windows but it doesn't seem, that they are intended to be used as such.

Apart from these objects, there doesn't seem to be another option.

[KaleiAlma]

so i just got sucked into a rabbit hole because of this issue, but eventually it led me to this: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/204

this seems like it could remove the dependency on needing to set the window position manually, and instead would attach a toplevel window to a drag-move action

still the fact that wayland doesn't support setting window position is wild to me (as someone who recently switched to wayland, having been using linux for a while beforehand as well)

however, this wayland feature is still relatively new and isn't supported by too many compositors yet...