Allow introspection of WindowBuilder default values.

[spearman]

Makes WindowAttributes public and add window_attributes() getter to WindowBuilder.

In version 0.27, the WindowAttributes struct was made private, but this removed the ability to introspect the default WindowBuilder values.

• Tested on all platforms changed
• Added an entry to CHANGELOG.md 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
• Updated feature matrix, if new features were added or implemented

[kchibisov]

Could you show the use case for introspection? Are you passing Builder around and build your stuff based on winit?

[mitchmindtree]

+1, in nannou we wrap winit's WindowBuilder and extend it with a custom API that allows for building the window alongside a wgpu surface and some other window-related items. Before finally building the window, we inspect the WindowAttributes for things like sizes, fullscreen, transparency etc in order to initialize surfaces/textures, determine defaults, etc.

The removal of access to WindowAttributes is a blocker for us in updating to wgpu 0.14, as wgpu 0.14 is only compatible with winit 0.27. Without something like this PR to re-introduce access to WindowAttributes, we'd require a significant refactor to track all of these attributes during the builder process ourselves.

[madsmtm]

Hmm, I was really hoping we could avoid this, but I guess this is still strictly better than what we previously had (which would've been unsound, since it would now have allowed &mut window_attributes.parent_window).

Would it be possible to instead implement getter methods for the things you need (like already done with WindowBuilder::transparent)? That makes it easier for us to avoid breaking changes in the future, as well as allowing internal refactors (like the fullscreen state-thing that's reverted here).
Though I guess if you need to access a lot of the state, it might just be more of a hazzle than a help, so I'm open for simply being pragmatic and just doing a #[non_exhaustive].

[madsmtm]

Also, I'm confused as to why you're doing all that extra work?

I understand why you're setting min_inner_size to the minimum physical size (2, 2) (should perhaps be (1, 1) logical size?), since you intend to render into the surface, but the inner_size stuff I don't understand? winit sets a default size automatically, so there shouldn't be a need for you to do that as well?

[mitchmindtree]

winit sets a default size automatically, so there shouldn't be a need for you to do that as well?

I don't remember why we do this exactly, but off the top of my head likely one of the following:

1. Because we need to know what the dimensions will be before the window itself is constructed, but afaik winit provides no way to know this.
2. By providing our own default, we don't have to worry about whether or not winit decides to change its defaults, or if it decides to use OS defaults which are also prone to change.

Would it be possible to instead implement getter methods for the things you need (like already done with WindowBuilder::transparent)? That makes it easier for us to avoid breaking changes in the future, as well as allowing internal refactors (like the fullscreen state-thing that's reverted here).
Though I guess if you need to access a lot of the state, it might just be more of a hazzle than a help, so I'm open for simply being pragmatic and just doing a #[non_exhaustive].

I don't really mind either way. I'm more concerned about functionality being used for yrs disappearing altogether with no alternative 🥲 but as a winit maintainer alumni I can empathise with your efforts to ease maintenance.

[madsmtm]

1. Because we need to know what the dimensions will be _before_ the window itself is constructed, but afaik winit provides no way to know this.

I just checked your code, it seems like this isn't the case.

2. By providing our own default, we don't have to worry about whether or not winit decides to change its defaults, or if it decides to use OS defaults which are also prone to change.

I would argue that's a feature - nannou's default won't be suitable on mobile devices, for example, while winit is in a better position to abstract that detail away.

I don't really mind either way. I'm more concerned about functionality being used for yrs disappearing altogether with no alternative 🥲

Yeah, I can understand, the reason for removal was mostly that I suspected it wasn't being used at all (which is still largely true; only some parts of the struct is used, so we can still cut down on our API surface).

but as a winit maintainer alumni I can empathise with your efforts to ease maintenance.

Thanks for your input, and again, I'm not that against reverting the change (like, these are minor details, I'd rather spend time on the more important stuff).

[mitchmindtree]

I suspected it wasn't being used at all (which is still largely true; only some parts of the struct is used, so we can still cut down on our API surface).

I think deprecating APIs to reduce the maintenance burden is fair, but please be careful about making assumptions around lack-of-use. If a pub API has already been exposed for a significant amount of time (this particular API has been around since before winit existed and we only had glutin, at least 8 years from memory), as a library maintainer, it's safer to assume it is being used by someone.

[madsmtm]

Yeah good point, I do sometimes forget how old this project is!

[spearman]

For my code it was purely informational, I had some routines that log out various defaults and runtime state from winit/glutin and glium, including the WindowAttributes defaults.

[daxpedda]

Cc #2134, which this PR reverts.