System Theme vs Window Theme

[daxpedda]

In #3736 the meaning of Window::theme() was changed to not return the system theme, ergo returning None without a theme override through Window::set_theme().
This is how currently MacOS works, but not how Web and Windows do.

I propose the following change:

• The meaning of Window::theme() should be changed to return the current window theme, if no override is in place it returns the system theme. I think a use-case for only returning an override has yet to be observed.
• MacOS should return the system theme in Window::theme() if no theme override is in place.
• A new ActiveEventLoop::system_theme() method should be introduced that returns the system theme.
• (optional) A new Window::system_theme() convenience method should be added that returns the same as ActiveEventLoop::system_theme().

Cc @madsmtm.

[tronical]

I like that proposal. Would you accept a PR that could be included in 0.30.x that follows up on #3736 and makes theme() on macOS fall back to effectiveAppearance? Something like this (untested):

let window = self.window();
Some(appearance_to_theme(unsafe { &*window.appearance().unwrap_or_else(|| &*window.effectiveAppearance()) }))

[daxpedda]

A PR (#3838) is already in place.
We have to come to a consensus though what the actual definition of Window::theme() should become before we discuss any backporting.

[tronical]

Ah great, thanks :)