Skip to content

Modal Dialog - #4627

Open
Murmele wants to merge 2 commits into
rust-windowing:masterfrom
Murmele:mm/modal-dialog
Open

Murmele wants to merge 2 commits into
rust-windowing:masterfrom
Murmele:mm/modal-dialog

Conversation

@Murmele

@Murmele Murmele commented Jul 13, 2026 •

Copy link
Copy Markdown
Contributor

Implement modal dialogs. This branch is based on the work of the Popup branch so this must be merged first. Only the last commit here is relevant for dialog

  • 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

What is missing to be ready

Os

  • Wayland (Xdg Dialog v1)
  • X11
  • Windows
  • MacOs

@redstrate

Copy link
Copy Markdown

Implement modal dialogs. This branch is based on the work of the Popup branch so this must be merged first. Only the last commit here is relevant for dialog

Was that #4543 ?

@Murmele

Murmele commented Sep 14, 2026

Copy link
Copy Markdown
Contributor Author

Implement modal dialogs. This branch is based on the work of the Popup branch so this must be merged first. Only the last commit here is relevant for dialog

Was that #4543 ?

Yes it was

#Conflicts:
#	winit-appkit/src/window_delegate.rs
#	winit-wayland/src/event_loop/mod.rs
#	winit-wayland/src/popup.rs
#	winit-wayland/src/window/common.rs
#	winit-win32/src/window.rs
#	winit-x11/src/window.rs
@Murmele
Murmele marked this pull request as ready for review September 25, 2026 09:57
@ogoffart

Copy link
Copy Markdown
Contributor

@dhardy , since you had opinions about the Popup change, maybe you want to have a look at this?

@dhardy dhardy left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking just at the API, this seems acceptable.

That said, I'm not wildly enthusiastic about pushing all of the window properties into WindowAttributes: it is left to documentation to describe which attributes are applicable to which window types. I can see two possible alternatives here:

  1. Moving attributes applicable to only one window type into WindowType variant fields (e.g. title and icon should only be applicable to full windows).
  2. Having separate create_window, create_popup and create_dialog methods, each with their own _Attributes struct.
  3. (Variant of above): create_window + create_subwindow with WindowType only used in the latter case; the rationale being that all subwindows need a parent.

Comment thread winit-core/src/window.rs
pub window_type: WindowType,
/// See [`WindowAttributes::with_positioner`].
pub positioner: Option<WindowPositioner>,
pub modal: Option<bool>,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why Option<bool>? What happens if this is None with WindowType::Dialog?

Comment thread winit-core/src/window.rs
/// - **X11, Web, Android, iOS, Orbital:** An error is returned because it is not implemented.
///
/// [owned windows]: https://learn.microsoft.com/en-us/windows/win32/winmsg/window-features#owned-windows
Dialog,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly it would make sense to put modal: bool under WindowType::Dialog since it is not applicable to any other window type.

(The same may apply to popup positioning information, but if so best leave that to another PR.)

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants