Wayland, Windows, MacOS: Popup Implementation#4543
Conversation
facdfde to
87f6327
Compare
Reason: Because a normal window can have a parent window as well, like a Dialog
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
Reason: Because it exists only for wayland
| anchor_rect_position.x + anchor_position.x, | ||
| anchor_rect_position.y + anchor_position.y, |
There was a problem hiding this comment.
Why do you add this? That doesn't seem correct. The anchor should be what is specified in the anchor_rect_position verbatim, this is what the user asked for.
Edit: i've read your comment more carefully, and i think i understand it now.
I'm a bit torn whether we should document that and make sure the dev add the window decoration in account when calling set_anchor_rect.
There was a problem hiding this comment.
I think if a frame is used, the position of the frame shall be considered automatically. This is the most common usecase. If you create a custom frame (Currently not supported by winit) and you create a popup you have to consider but then you are also quite deep in the topic and you know what you are doing
| anchor_rect_size.width.max(1), | ||
| anchor_rect_size.height.max(1), | ||
| ); | ||
| positioner.set_offset(position.x, position.y); |
There was a problem hiding this comment.
is this behavior documented?
Reason: the positioner does not allow zero size then we get a protocol error
| pub surface_resize_increments: Option<Size>, | ||
| /// The initial position of the window in screen coordinates. | ||
| /// | ||
| /// For popups, this position is relative to the parent window. |
There was a problem hiding this comment.
inner our outer position?
…as normal position
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
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. IfPopupis choosen a parent must be specified, otherwise the Popup creation fails with an Error returned by thenew()function.Related issues: #403 and #4256
changelogmodule if knowledge of this change could be valuable to usersPlatforms
Wayland:
Bildschirmaufzeichnung.vom.2026-06-04.13-18-16.mp4
This work is sponsored by the NLnet foundation