Wayland, Windows, MacOS: Popup Implementation by Murmele · Pull Request #4543 · rust-windowing/winit

Murmele · 2026-03-25T06:58:46Z

Implement proper decorationless popups by specifying the type of the child window with with_type()

With this PR different kind of child windows can be created

Popups: Special windows without any decoration which can be positioned relative to the parent
Window: Normal window with a parent or not

The type can be specified during creation of the Window using the window_attributes and the with_type() function. As default a normal Window is used. If Popup is choosen a parent must be specified, otherwise the Popup creation fails with an Error returned by the new() function.

Related issues: #403 and #4256

Tested on all platforms changed
Added an entry to the changelog module if knowledge of this change could be valuable to users
Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
Created or updated an example program if it would help users understand this functionality

Platforms

Wayland
Windows
MacOs
X11

Wayland:

Bildschirmaufzeichnung.vom.2026-06-04.13-18-16.mp4

This work is sponsored by the NLnet foundation

Reason: Because a normal window can have a parent window as well, like a Dialog

…pups

Reason: otherwise the child surface is anchored to the center

Reason: otherwise the height of the client side decoration is not considered and therefore the location is shifted

Reason: There are multiple pointers to the smithay popup. Once in state.windows and one time in the popup object it self. Just dropping the popup object releases only one pointer but we have to notify the state to release also the other

…he position Reason: Much easier in the resize handle

Reason: we have to call resize to initialize the viewport to map to correct window size

Murmele · 2026-06-08T09:31:26Z

@kchibisov Just in case you have time. This is ready for review

CryZe · 2026-06-08T09:41:48Z

I'd like to review it too. I've been using an earlier version of this branch for my own project and I had some local bugfixes (various panics, protocol violations and commented out / unimplemented code). I'll try to rebase and see if your PR now contains all of them.

Murmele · 2026-06-08T11:16:32Z

I'd like to review it too. I've been using an earlier version of this branch for my own project and I had some local bugfixes (various panics, protocol violations and commented out / unimplemented code). I'll try to rebase and see if your PR now contains all of them.

Thanks for testing, just let me know if you have any problems

tronical · 2026-06-08T13:37:06Z

+    ///
+    /// See [`WindowType::Popup`] for the per-platform behavior, including how to obtain a
+    /// rounded, native-looking popup on macOS.
+    pub fn with_type(mut self, window_type: WindowType) -> Self {


I'm inclined to suggest to call this with_window_type. That would also make it symmetric to window_type().

thanks I changed it

tronical · 2026-06-08T13:38:39Z

+    /// tooltip. Requires a parent set via [`WindowAttributes::with_parent_window`], and its
+    /// position is interpreted relative to that parent.
+    ///
+    /// ## Platform-specific


I think this would be the place to mention that this is for example not supported on X11 (as opposed to just with with_type())

tronical · 2026-06-08T13:42:55Z

+                let popup = crate::Popup::new(self, window_attributes)?;
+                Ok(Box::new(popup))
+            },
+            _ => panic!("Not implemented"),


Since the function returns a Result, wouldn't it perhaps make sense to return Err instead of a panic?

Alternatively, unimplemented!() perhaps?

(sucks that non_exhaustive doesn't kick in here - I wonder if there's a way?)

tronical · 2026-06-08T13:44:19Z

+    Window((Window, Option<WindowConfigure>)),
+    Popup((Popup, XdgPositioner, Option<PopupConfigure>)),


Tuples are tempting, but .1 and .2 aren't super readable. I'd lean towards anonymous structs inside the enum.

true, makes it much more readable :)

tronical · 2026-06-08T13:47:33Z

+    // If we have a popup the position is relative to the parent window and not
+    // relative to the screen. Therefore we have to translate it from the parent
+    // coordinate system to the display coordinate system
+    fn translate_outer_position(&self, position: Position) -> (i32, i32) {


Perhaps this should return a PhysicalPosition instead of a tuple, to reduce changes of mixing this up?

Reason: So it is clear which kind of position it is

CryZe · 2026-06-12T14:36:32Z

Alright, so far I've confirmed 2 out of 3 bugs:

Popups need to be closed in reverse order (children before parents), otherwise you get a protocol violation:

xdg_wm_base#14: error 2: destroyed popup not top most popup

Fix here: CryZe@a157156

This may be unrelated to this PR a bit, but I noticed this when popups get closed, sometimes the compositor updates still get processed by the event loop and it panics on a None unwrap because the window no longer exists:

thread 'main' (26750) panicked at vendor/winit/winit-wayland/src/event_loop/mod.rs:361:58:
called `Option::unwrap()` on a `None` value

Fix here: CryZe@3d03cab

Both of these fixes are quickly put together, there's possibly a better way to do it. I'm still looking into the third bugfix, at least so far it doesn't seem to do anything anymore on your branch (as in, you probably already fixed it).

kchibisov · 2026-06-12T17:57:44Z

I think the idea with those pop-ups were to have a separate type other than glue to window, because as you said, they are very restricted on some platforms and on some platform it's indeed just a Window.

so in top-level API I would have them, as a separate type with its own restrictions, and what not, I'm also not sure if those things can be owned by the user, really, I think popups should be more like something you create from e.g. Window so Window::create_popup type of API call, that may take an ActiveEventLoop or ActiveEventLoop. EventLoop having an api like ActiveEventLoop::create_pop(&dyn Window, PopupProperties) as generally better in my opinion.

Popups need to be closed in reverse order (children before parents), otherwise you get a protocol violation:

Exactly why I want to have them owned by Parent, whether it's window or some other thing.

Generally, I think the initial plan was to have some kind of trait Surface and then for event loop to have ActiveEventLoop::create_popup(&mut dyn Surface, so it adds popup for the Surface so API is a bit more future proof.

@tronical would like to hear your opinion here since you're representing ui toolkit side 😅

I just want to account for other special surfaces Wayland people can create which has their own popup type that is certainly not different than standard popup.

tronical · 2026-06-12T18:57:22Z

I think the idea with those pop-ups were to have a separate type other than glue to window, because as you said, they are very restricted on some platforms and on some platform it's indeed just a Window.

so in top-level API I would have them, as a separate type with its own restrictions, and what not, I'm also not sure if those things can be owned by the user, really, I think popups should be more like something you create from e.g. Window so Window::create_popup type of API call, that may take an ActiveEventLoop or ActiveEventLoop. EventLoop having an api like ActiveEventLoop::create_pop(&dyn Window, PopupProperties) as generally better in my opinion.

Popups need to be closed in reverse order (children before parents), otherwise you get a protocol violation:

Exactly why I want to have them owned by Parent, whether it's window or some other thing.

That's indeed an interesting constraint (reverse order required).

Generally, I think the initial plan was to have some kind of trait Surface and then for event loop to have ActiveEventLoop::create_popup(&mut dyn Surface, so it adds popup for the Surface so API is a bit more future proof.

@tronical would like to hear your opinion here since you're representing ui toolkit side 😅

I just want to account for other special surfaces Wayland people can create which has their own popup type that is certainly not different than standard popup.

I see the discrepancy, but I also see that - wayland aside - popups have more in common with Window than not. Another surface abstraction is tempting indeed, but my feeling is that it may be worthwhile to go with this approach first and learn from it.

(disclaimer: I'm biased though as I'm Martin's colleague :)

kchibisov · 2026-06-12T20:11:56Z

The problem with Wayland, is that if you randomly use it wrongly, it really likes killing applications with protocol errors, so my suggestion is mostly to try solve it on type system level, or at least make it less likely, so users won't have to debug Wayland when it breaks in their cross platform app.

I also remember that popups can be discarded/removed on user behalf and winit window is kind of persistent now.

HigherOrderLogic · 2026-06-13T15:08:09Z

For Wayland: shouldnt we also use the xdg-dialog-v1 protocol to mark it as dialog? This implementation doesnt seems to use that protocol atm.

kchibisov · 2026-06-13T16:09:14Z

I think dialog protocol serves a different purpose, and also not widely available?

HigherOrderLogic · 2026-06-13T16:24:23Z

I think dialog protocol serves a different purpose

Ah right, I didnt read the PR description carefully, my bad. Originally thought it was popup dialog.

and also not widely available?

All 3 most popular compositors right now, KWin, Mutter and Hyprland, implement it so I dont think it's a problem.

madsmtm added DS - wayland Affects the Wayland backend, or generally free Unix platforms S - platform parity Unintended platform differences labels Mar 26, 2026

Murmele commented May 15, 2026

View reviewed changes

Comment thread winit-wayland/src/window/state.rs

Murmele commented May 15, 2026

View reviewed changes

Comment thread winit-wayland/src/window/state.rs Outdated

Murmele marked this pull request as ready for review May 18, 2026 08:06

Murmele requested a review from kchibisov as a code owner May 18, 2026 08:06

Murmele commented May 18, 2026

View reviewed changes

Comment thread winit-wayland/src/state.rs Outdated

Comment thread winit-wayland/src/state.rs Outdated

ogoffart reviewed May 18, 2026

View reviewed changes

Murmele commented May 26, 2026

View reviewed changes

Comment thread winit-win32/src/window.rs

Murmele requested a review from madsmtm as a code owner May 28, 2026 15:09

Murmele force-pushed the popup branch 2 times, most recently from facdfde to 87f6327 Compare June 4, 2026 12:59

Murmele added 15 commits June 4, 2026 15:07

initial commit to implement popup

bd6dea9

use dedicated type to determine if the window is a popup or not

ae3178c

Reason: Because a normal window can have a parent window as well, like a Dialog

determine the scale factor from the parent window

8f42bbc

add comment, thtat positioning is now also working on wayland with po…

933939a

…pups

set the positioner gravity

d43d6ad

Reason: otherwise the child surface is anchored to the center

cleanup

6dc05a7

consider the location of the frame for client side decoration

68e33bf

Reason: otherwise the height of the client side decoration is not considered and therefore the location is shifted

extend comment

a4d299b

fix closing popups

3514818

Reason: There are multiple pointers to the smithay popup. Once in state.windows and one time in the popup object it self. Just dropping the popup object releases only one pointer but we have to notify the state to release also the other

implement resizing of the popup using the positioner

a02e2c3

Positioner: Set anchor point once and then use the offset to change t…

9371aca

…he position Reason: Much easier in the resize handle

implement popup for macos

4eb2667

implement popup for windows

3c0d318

Fix popup size for different scalings

39e35d0

Reason: we have to call resize to initialize the viewport to map to correct window size

Merge commit 'c4afadbfabf7b1e7989b40b493db1a4c7bd8ff4e'

78bfc78

Murmele force-pushed the popup branch from 87f6327 to 78bfc78 Compare June 4, 2026 13:17

add changelog entry

9c33bdc

Murmele changed the title ~~Wayland: Popup Implementation~~ Wayland, Windows, MacOS: Popup Implementation Jun 4, 2026

update example to show how to use the WindowType

08ac037

Murmele force-pushed the popup branch from 74bfada to 2630133 Compare June 8, 2026 09:30

Murmele force-pushed the popup branch from 2630133 to aae23f1 Compare June 8, 2026 09:41

tronical reviewed Jun 8, 2026

View reviewed changes

Murmele added 2 commits June 10, 2026 16:55

Windows: return PhysicalPosition from translate_outer_position

736f391

Reason: So it is clear which kind of position it is

Fix review

19df2cd

Murmele force-pushed the popup branch from 2a05152 to 19df2cd Compare June 10, 2026 14:56

		Window((Window, Option<WindowConfigure>)),
		Popup((Popup, XdgPositioner, Option<PopupConfigure>)),

Conversation

Murmele commented Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Platforms

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Murmele commented Jun 8, 2026

Uh oh!

CryZe commented Jun 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Murmele commented Jun 8, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

CryZe commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kchibisov commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tronical commented Jun 12, 2026

Uh oh!

kchibisov commented Jun 12, 2026

Uh oh!

HigherOrderLogic commented Jun 13, 2026

Uh oh!

kchibisov commented Jun 13, 2026

Uh oh!

HigherOrderLogic commented Jun 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

7 participants

Murmele commented Mar 25, 2026 •

edited

Loading

CryZe commented Jun 8, 2026 •

edited

Loading

CryZe commented Jun 12, 2026 •

edited

Loading

kchibisov commented Jun 12, 2026 •

edited

Loading