Checking for macOS dark mode
256 views
Skip to first unread message
Vadim Zeitlin
Apr 8, 2019, 8:16:43 PM4/8/19
to wx-dev
Hi,
I think we need to have some function returning whether dark mode is used
under macOS 10.14+, as it turns out that, even though it's obviously a bad
idea, it's not uncommon to have some UI elements using hardcoded colours
such as black or white that become totally inappropriate for the dark mode
and so having some IsUsingDarkMode() function would be helpful to check
whether they shouldn't be used at all or reversed.
Implementing this function is apparently as simple as checking for
"AppleInterfaceStyle" value in the user defaults object. The only problem I
have with this approach is that it doesn't appear to be documented -- but
this is what everybody else seems to be using, so I guess it should be fine
to do it for us too. But please let me know if you know of any better way.
The main question is about how the API should look like, however, because
I'm not sure at all about where should this function go. AFAIK dark mode is
application-wide, i.e. it's impossible to have one TLW using it and another
one which doesn't, but I still wonder if it could make more sense to put
the function into TLW or even wxWindow, rather than wxApp, because it's
clearly GUI-related and you typically do always have a window at hand
anyhow anywhere were you need to set the colours. Another possibility would
be to add it to wxSystemSettings. Or maybe I'm overthinking this and we
should just have a global function?
To summarize, here are the various possibilities about what the new
function could be:
1. A new method of wxApp.
2. A new method of wxTopLevelWindow.
3. A new method of wxWindow.
4. A new method of wxSystemSettings.
5. A new parameter for wxSystemSettings::HasFeature().
6. A new global function.
Do you have any preferences?
And finally I also think that it could be useful to send a
wxSysColourChangedEvent when the mode changes as I believe that
applications are supposed to react to this dynamically, i.e. switching
to/from dark mode shouldn't require a restart. This could be implemented by
reacting to (also undocumented) AppleInterfaceThemeChangedNotification,
according to what I saw, but any comments about this would be welcome as
well, of course.
TIA!
VZ
I think we need to have some function returning whether dark mode is used
under macOS 10.14+, as it turns out that, even though it's obviously a bad
idea, it's not uncommon to have some UI elements using hardcoded colours
such as black or white that become totally inappropriate for the dark mode
and so having some IsUsingDarkMode() function would be helpful to check
whether they shouldn't be used at all or reversed.
Implementing this function is apparently as simple as checking for
"AppleInterfaceStyle" value in the user defaults object. The only problem I
have with this approach is that it doesn't appear to be documented -- but
this is what everybody else seems to be using, so I guess it should be fine
to do it for us too. But please let me know if you know of any better way.
The main question is about how the API should look like, however, because
I'm not sure at all about where should this function go. AFAIK dark mode is
application-wide, i.e. it's impossible to have one TLW using it and another
one which doesn't, but I still wonder if it could make more sense to put
the function into TLW or even wxWindow, rather than wxApp, because it's
clearly GUI-related and you typically do always have a window at hand
anyhow anywhere were you need to set the colours. Another possibility would
be to add it to wxSystemSettings. Or maybe I'm overthinking this and we
should just have a global function?
To summarize, here are the various possibilities about what the new
function could be:
1. A new method of wxApp.
2. A new method of wxTopLevelWindow.
3. A new method of wxWindow.
4. A new method of wxSystemSettings.
5. A new parameter for wxSystemSettings::HasFeature().
6. A new global function.
Do you have any preferences?
And finally I also think that it could be useful to send a
wxSysColourChangedEvent when the mode changes as I believe that
applications are supposed to react to this dynamically, i.e. switching
to/from dark mode shouldn't require a restart. This could be implemented by
reacting to (also undocumented) AppleInterfaceThemeChangedNotification,
according to what I saw, but any comments about this would be welcome as
well, of course.
TIA!
VZ
New Pagodi
Apr 8, 2019, 9:05:37 PM4/8/19
to wx-dev
I was going to make a similar suggestion. I think it would be a good idea to also provide this information for windows 10. I know for now that this is of limited value since for now only the UWP controls are actually governed by that theme. But it could still be useful if a wxWidgets application uses custom cotrols or colors system controls (as much as possible) to match a dark theme.
However the way to do this is currently undocumented and requires checking the registry key:
Software\\Microsoft\\Windows\\CurrentVersion\\Themes\\Personalize\\AppsUseLightThemeChanges to the theme can also be detected with the WM_SETTINGCHANGE message, but that message really supplies no useful info with its lparam/wparam data. Also that message is sent for many reasons, and so the only way to see if it's actually for a system theme change is to first cache the
AppsUseLightTheme value then recompute and compare it when that message is received.With windows 10, there's also a system accent color whose value is not currently accessable from wxWidgets code. It's similarly stored in a registry value and changes can be detected with the WM_SETTINGCHANGE message.
For GTK+ there's obviously no system light/dark theme - just a variety of themes some of which call themselves light or dark. But we could implement a function like this (except I would base the classification of luminance instead of simply adding the component values).
I'd be willing to work on/help work on this stuff it seems like a worthwhile addition to the library.
And finally I also think that it could be useful to send a
wxSysColourChangedEvent when the mode changes as I believe that
applications are supposed to react to this dynamically, i.e. switching
to/from dark mode shouldn't require a restart. This could be implemented by
reacting to (also undocumented) AppleInterfaceThemeChangedNotification,
according to what I saw, but any comments about this would be welcome as
well, of course.
I think this already happens. I know when I was working on the STC popup stuff, I was able to make the popup respond to changing the theme from light to dark by handing the wxSysColourChangedEvent.
Igor Korot
Apr 8, 2019, 9:07:07 PM4/8/19
to wx-dev
Hi, (Vadim),
I don't have 10.14, but here are couple of questions:
1. Is standard Apple icons in the TaskBar (i.e. Finder) looks the same
under Dark Mode
and not?
2. If they are different, when switching, does the coloring changes?
Because if the answers are yes - it is probably belong to
wxSystemSettings/wxApp...
Thank you.
>
> TIA!
> VZ
1. Is standard Apple icons in the TaskBar (i.e. Finder) looks the same
under Dark Mode
and not?
2. If they are different, when switching, does the coloring changes?
Because if the answers are yes - it is probably belong to
wxSystemSettings/wxApp...
Thank you.
>
> TIA!
> VZ
Vadim Zeitlin
Apr 8, 2019, 11:09:32 PM4/8/19
to wx-...@googlegroups.com
On Mon, 8 Apr 2019 18:05:37 -0700 (PDT) New Pagodi wrote:
NP> I was going to make a similar suggestion. I think it would be a good idea
NP> to also provide this information for windows 10. I know for now that this
NP> is of limited value since for now only the UWP controls are actually
NP> governed by that theme. But it could still be useful if a wxWidgets
NP> application uses custom cotrols or colors system controls (as much as
NP> possible) to match a dark theme.
Yes, it would definitely be nice to generalize this API to the other
systems, but first I'd like to decide how it should look like and implement
it for macOS, as this is where I actually need it today.
NP> However the way to do this is currently undocumented and requires checking
NP> the registry key:
NP>
NP> Software\\Microsoft\\Windows\\CurrentVersion\\Themes\\Personalize\\
NP> AppsUseLightTheme
Thanks, I didn't know about this. As for being undocumented, it just seems
to be an intrinsic property of the APIs we need to use to determine this...
NP> Changes to the theme can also be detected with the WM_SETTINGCHANGE
NP> message, but that message really supplies no useful info with its
NP> lparam/wparam data. Also that message is sent for many reasons, and so the
NP> only way to see if it's actually for a system theme change is to first
NP> cache the AppsUseLightTheme value then recompute and compare it when that
NP> message is received.
This looks like a good idea.
NP> For GTK+ there's obviously no system light/dark theme - just a variety of
NP> themes some of which call themselves light or dark. But we could implement
NP> a function like this <https://lzone.de/blog/Detecting+a+Dark+Theme+in+GTK>
NP> (except I would base the classification of luminance instead of simply
NP> adding the component values).
Yes, this also looks reasonable.
NP> I'd be willing to work on/help work on this stuff it seems like a
NP> worthwhile addition to the library.
Thanks! Your contributions would, of course, be welcome, as always, but we
still need to decide on the API first.
NP> > And finally I also think that it could be useful to send a
NP> > wxSysColourChangedEvent when the mode changes as I believe that
NP> > applications are supposed to react to this dynamically, i.e. switching
NP> > to/from dark mode shouldn't require a restart. This could be implemented
NP> > by reacting to (also undocumented)
NP> > AppleInterfaceThemeChangedNotification, according to what I saw, but
NP> > any comments about this would be welcome as well, of course.
NP>
NP> I think this already happens. I know when I was working on the STC popup
NP> stuff, I was able to make the popup respond to changing the theme from
NP> light to dark by handing the wxSysColourChangedEvent.
Interesting, I wonder where is it generated from. In any case, we probably
still need to add some wxSysColourChangedEvent accessor allowing to check
if this event corresponds to the global theme change, what do you think?
Thanks,
VZ
NP> I was going to make a similar suggestion. I think it would be a good idea
NP> to also provide this information for windows 10. I know for now that this
NP> is of limited value since for now only the UWP controls are actually
NP> governed by that theme. But it could still be useful if a wxWidgets
NP> application uses custom cotrols or colors system controls (as much as
NP> possible) to match a dark theme.
Yes, it would definitely be nice to generalize this API to the other
systems, but first I'd like to decide how it should look like and implement
it for macOS, as this is where I actually need it today.
NP> However the way to do this is currently undocumented and requires checking
NP> the registry key:
NP>
NP> Software\\Microsoft\\Windows\\CurrentVersion\\Themes\\Personalize\\
NP> AppsUseLightTheme
Thanks, I didn't know about this. As for being undocumented, it just seems
to be an intrinsic property of the APIs we need to use to determine this...
NP> Changes to the theme can also be detected with the WM_SETTINGCHANGE
NP> message, but that message really supplies no useful info with its
NP> lparam/wparam data. Also that message is sent for many reasons, and so the
NP> only way to see if it's actually for a system theme change is to first
NP> cache the AppsUseLightTheme value then recompute and compare it when that
NP> message is received.
This looks like a good idea.
NP> For GTK+ there's obviously no system light/dark theme - just a variety of
NP> themes some of which call themselves light or dark. But we could implement
NP> a function like this <https://lzone.de/blog/Detecting+a+Dark+Theme+in+GTK>
NP> (except I would base the classification of luminance instead of simply
NP> adding the component values).
Yes, this also looks reasonable.
NP> I'd be willing to work on/help work on this stuff it seems like a
NP> worthwhile addition to the library.
Thanks! Your contributions would, of course, be welcome, as always, but we
still need to decide on the API first.
NP> > And finally I also think that it could be useful to send a
NP> > wxSysColourChangedEvent when the mode changes as I believe that
NP> > applications are supposed to react to this dynamically, i.e. switching
NP> > to/from dark mode shouldn't require a restart. This could be implemented
NP> > by reacting to (also undocumented)
NP> > AppleInterfaceThemeChangedNotification, according to what I saw, but
NP> > any comments about this would be welcome as well, of course.
NP>
NP> I think this already happens. I know when I was working on the STC popup
NP> stuff, I was able to make the popup respond to changing the theme from
NP> light to dark by handing the wxSysColourChangedEvent.
Interesting, I wonder where is it generated from. In any case, we probably
still need to add some wxSysColourChangedEvent accessor allowing to check
if this event corresponds to the global theme change, what do you think?
Thanks,
VZ
Catalin
Apr 9, 2019, 1:29:18 AM4/9/19
to wx-...@googlegroups.com
On Tuesday, 9 April 2019, 06:09:33 EEST, Vadim Zeitlin wrote:
> On Mon, 8 Apr 2019 18:05:37 -0700 (PDT) New Pagodi wrote:
NP> Changes to the theme can also be detected with the WM_SETTINGCHANGE
NP> message, but that message really supplies no useful info with its
NP> lparam/wparam data. Also that message is sent for many reasons, and so the
NP> only way to see if it's actually for a system theme change is to first
NP> cache the AppsUseLightTheme value then recompute and compare it when that
NP> message is received.
> This looks like a good idea.
A couple of other suggestions on stack overflow:
> On Mon, 8 Apr 2019 18:05:37 -0700 (PDT) New Pagodi wrote:
NP> Changes to the theme can also be detected with the WM_SETTINGCHANGE
NP> message, but that message really supplies no useful info with its
NP> lparam/wparam data. Also that message is sent for many reasons, and so the
NP> only way to see if it's actually for a system theme change is to first
NP> cache the AppsUseLightTheme value then recompute and compare it when that
NP> message is received.
> This looks like a good idea.
- use RegNotifyChangeKeyValue to be notified when the relevant theme reg key has changed;
- ``listen for WM_WININICHANGE broadcast - lParam == "ImmersiveColorSet"``, although the docs suggest that this message is deprecated.
Regards,
C
New Pagodi
Apr 9, 2019, 7:27:42 AM4/9/19
to wx-dev
On Monday, April 8, 2019 at 10:09:32 PM UTC-5, VZ wrote:
Yes, it would definitely be nice to generalize this API to the other
systems, but first I'd like to decide how it should look like and implement
it for macOS, as this is where I actually need it today.
I would propose adding a method to wxSystemSettings named something like GetSystemThemeType returning an enumeration value like
wxSYSTEM_THEME_DARK
wxSYSTEM_THEME_LIGHT
wxSYSTEM_THEME_UNKNOWN
wxSYSTEM_THEME_LIGHT
wxSYSTEM_THEME_UNKNOWN
I don't really have a good argument but that's what makes the most sense to me.
However it might also be useful to have a convenience function in wxApp named something like IsSystemThemeDark() which internally calls the wxSystemSettings method. However that method might look dated in 10 years when everyone has moved on from dark themes to purple themes (or whatever comes next).
Personally I don't think it makes sense to add it to wxWindow or even the top level window class because it really is a system setting.
Interesting, I wonder where is it generated from. In any case, we probably
still need to add some wxSysColourChangedEvent accessor allowing to check
if this event corresponds to the global theme change, what do you think?
That does seem like a good idea.
Those are my suggestions for the API.
Stefan Csomor
Apr 9, 2019, 1:23:49 PM4/9/19
to wx-...@googlegroups.com
Hi
I think we need to have some function returning whether dark mode is used
under macOS 10.14+, as it turns out that, even though it's obviously a bad
idea, it's not uncommon to have some UI elements using hardcoded colours
such as black or white that become totally inappropriate for the dark mode
and so having some IsUsingDarkMode() function would be helpful to check
whether they shouldn't be used at all or reversed.
Implementing this function is apparently as simple as checking for
"AppleInterfaceStyle" value in the user defaults object. The only problem I
have with this approach is that it doesn't appear to be documented -- but
this is what everybody else seems to be using, so I guess it should be fine
to do it for us too. But please let me know if you know of any better way.
the thing is that there are several elements involved to decide whether the app runs really in certain mode,
wxOSXEffectiveAppearanceSetter makes sure, the current appearance is correct, then colors are correctly resolved
In the emulated statusbar we use the value of the red channel of a certain system color to determine whether we are
really in dark mode
wxColour bg = wxSystemSettings::GetColour(wxSYS_COLOUR_APPWORKSPACE);
if ( bg.Red() < 128 )
{
// dark mode appearance
The main question is about how the API should look like, however, because
I'm not sure at all about where should this function go. AFAIK dark mode is
application-wide, i.e. it's impossible to have one TLW using it and another
one which doesn't, but I still wonder if it could make more sense to put
the function into TLW or even wxWindow, rather than wxApp, because it's
clearly GUI-related and you typically do always have a window at hand
anyhow anywhere were you need to set the colours. Another possibility would
be to add it to wxSystemSettings. Or maybe I'm overthinking this and we
should just have a global function?
so this could be encapsulated in a system function, to me wxSystemSettings first comes to mind
To summarize, here are the various possibilities about what the new
function could be:
1. A new method of wxApp.
2. A new method of wxTopLevelWindow.
3. A new method of wxWindow.
4. A new method of wxSystemSettings.
5. A new parameter for wxSystemSettings::HasFeature().
6. A new global function.
Do you have any preferences?
And finally I also think that it could be useful to send a
wxSysColourChangedEvent when the mode changes as I believe that
applications are supposed to react to this dynamically, i.e. switching
to/from dark mode shouldn't require a restart. This could be implemented by
reacting to (also undocumented) AppleInterfaceThemeChangedNotification,
according to what I saw, but any comments about this would be welcome as
well, of course.
this is already the case (at least if there is a toplevel window), reacting to changes of effectiveAppearance happens in nonownedwnd.mm lines 627ff.
Best,
Stefan
I think we need to have some function returning whether dark mode is used
under macOS 10.14+, as it turns out that, even though it's obviously a bad
idea, it's not uncommon to have some UI elements using hardcoded colours
such as black or white that become totally inappropriate for the dark mode
and so having some IsUsingDarkMode() function would be helpful to check
whether they shouldn't be used at all or reversed.
Implementing this function is apparently as simple as checking for
"AppleInterfaceStyle" value in the user defaults object. The only problem I
have with this approach is that it doesn't appear to be documented -- but
this is what everybody else seems to be using, so I guess it should be fine
to do it for us too. But please let me know if you know of any better way.
wxOSXEffectiveAppearanceSetter makes sure, the current appearance is correct, then colors are correctly resolved
In the emulated statusbar we use the value of the red channel of a certain system color to determine whether we are
really in dark mode
wxColour bg = wxSystemSettings::GetColour(wxSYS_COLOUR_APPWORKSPACE);
if ( bg.Red() < 128 )
{
// dark mode appearance
The main question is about how the API should look like, however, because
I'm not sure at all about where should this function go. AFAIK dark mode is
application-wide, i.e. it's impossible to have one TLW using it and another
one which doesn't, but I still wonder if it could make more sense to put
the function into TLW or even wxWindow, rather than wxApp, because it's
clearly GUI-related and you typically do always have a window at hand
anyhow anywhere were you need to set the colours. Another possibility would
be to add it to wxSystemSettings. Or maybe I'm overthinking this and we
should just have a global function?
To summarize, here are the various possibilities about what the new
function could be:
1. A new method of wxApp.
2. A new method of wxTopLevelWindow.
3. A new method of wxWindow.
4. A new method of wxSystemSettings.
5. A new parameter for wxSystemSettings::HasFeature().
6. A new global function.
Do you have any preferences?
And finally I also think that it could be useful to send a
wxSysColourChangedEvent when the mode changes as I believe that
applications are supposed to react to this dynamically, i.e. switching
to/from dark mode shouldn't require a restart. This could be implemented by
reacting to (also undocumented) AppleInterfaceThemeChangedNotification,
according to what I saw, but any comments about this would be welcome as
well, of course.
Best,
Stefan
Vadim Zeitlin
Apr 9, 2019, 2:12:44 PM4/9/19
to wx-...@googlegroups.com
On Tue, 9 Apr 2019 17:23:46 +0000 Stefan Csomor wrote:
SC> the thing is that there are several elements involved to decide whether
SC> the app runs really in certain mode, wxOSXEffectiveAppearanceSetter
SC> makes sure, the current appearance is correct, then colors are
SC> correctly resolved
Hi,
Thanks for the reply, but I don't really understand why is this needed,
i.e. when would the app effective appearance be different from the current
appearance? Is there any good reason to even allow this to happen?
SC> In the emulated statusbar we use the value of the red channel of a
SC> certain system color to determine whether we are really in dark mode
SC>
SC> wxColour bg = wxSystemSettings::GetColour(wxSYS_COLOUR_APPWORKSPACE);
SC>
SC> if ( bg.Red() < 128 )
SC> {
SC> // dark mode appearance
This is more compatible with "is using dark theme" approach rather than
"is using the system dark mode" approach. It could be a better idea or not,
but I'm a bit surprised that you recommend doing it like this because
everything I found during my (admittedly brief) web search seemed to
recommend checking "AppleInterfaceStyle" value. Are the situations in which
these 2 methods would yield different results?
SC> so this could be encapsulated in a system function, to me
SC> wxSystemSettings first comes to mind
OK, as both you and New Pagodi prefer this, let's go with it. I'm still
not sure if it should be GetSystemThemeType(), as proposed by New Pagodi,
or just IsSystemThemeDark() as you seem to be leaning to?
SC> > And finally I also think that it could be useful to send a
SC> > wxSysColourChangedEvent when the mode changes as I believe that
SC> > applications are supposed to react to this dynamically, i.e. switching
SC> > to/from dark mode shouldn't require a restart. This could be implemented by
SC> > reacting to (also undocumented) AppleInterfaceThemeChangedNotification,
SC> > according to what I saw, but any comments about this would be welcome as
SC> > well, of course.
SC>
SC> this is already the case (at least if there is a toplevel window),
SC> reacting to changes of effectiveAppearance happens in nonownedwnd.mm
SC> lines 627ff.
Ah, thanks, I've totally missed this. We could just set a flag in the
event generated there telling that it notifies about the whole theme change
then. Or maybe even this is superfluous...
Regards,
VZ
SC> the thing is that there are several elements involved to decide whether
SC> the app runs really in certain mode, wxOSXEffectiveAppearanceSetter
SC> makes sure, the current appearance is correct, then colors are
SC> correctly resolved
Hi,
Thanks for the reply, but I don't really understand why is this needed,
i.e. when would the app effective appearance be different from the current
appearance? Is there any good reason to even allow this to happen?
SC> In the emulated statusbar we use the value of the red channel of a
SC> certain system color to determine whether we are really in dark mode
SC>
SC> wxColour bg = wxSystemSettings::GetColour(wxSYS_COLOUR_APPWORKSPACE);
SC>
SC> if ( bg.Red() < 128 )
SC> {
SC> // dark mode appearance
This is more compatible with "is using dark theme" approach rather than
"is using the system dark mode" approach. It could be a better idea or not,
but I'm a bit surprised that you recommend doing it like this because
everything I found during my (admittedly brief) web search seemed to
recommend checking "AppleInterfaceStyle" value. Are the situations in which
these 2 methods would yield different results?
SC> so this could be encapsulated in a system function, to me
SC> wxSystemSettings first comes to mind
OK, as both you and New Pagodi prefer this, let's go with it. I'm still
not sure if it should be GetSystemThemeType(), as proposed by New Pagodi,
or just IsSystemThemeDark() as you seem to be leaning to?
SC> > And finally I also think that it could be useful to send a
SC> > wxSysColourChangedEvent when the mode changes as I believe that
SC> > applications are supposed to react to this dynamically, i.e. switching
SC> > to/from dark mode shouldn't require a restart. This could be implemented by
SC> > reacting to (also undocumented) AppleInterfaceThemeChangedNotification,
SC> > according to what I saw, but any comments about this would be welcome as
SC> > well, of course.
SC>
SC> this is already the case (at least if there is a toplevel window),
SC> reacting to changes of effectiveAppearance happens in nonownedwnd.mm
SC> lines 627ff.
Ah, thanks, I've totally missed this. We could just set a flag in the
event generated there telling that it notifies about the whole theme change
then. Or maybe even this is superfluous...
Regards,
VZ
Gerald Brandt
Apr 9, 2019, 2:19:19 PM4/9/19
to wx-...@googlegroups.com
On 2019-04-09 1:12 p.m., Vadim Zeitlin wrote:
> SC> so this could be encapsulated in a system function, to me
> SC> wxSystemSettings first comes to mind
>
> OK, as both you and New Pagodi prefer this, let's go with it. I'm still
> not sure if it should be GetSystemThemeType(), as proposed by New Pagodi,
> or just IsSystemThemeDark() as you seem to be leaning to?
>
themes types are dark or light, but there could be others. I also
believe I read somewhere long ago in the wxWidgets docs to avoid binary
responses in wxWidgets (might have even been wxWIndows still) code.
Essentially, GetSystemThemeType() gives us room to grow if we need to.
Gerald
Vadim Zeitlin
Apr 9, 2019, 5:32:34 PM4/9/19
to wx-...@googlegroups.com
On Tue, 9 Apr 2019 13:19:09 -0500 Gerald Brandt wrote:
GB> On 2019-04-09 1:12 p.m., Vadim Zeitlin wrote:
GB> > SC> so this could be encapsulated in a system function, to me
GB> > SC> wxSystemSettings first comes to mind
GB> >
GB> > OK, as both you and New Pagodi prefer this, let's go with it. I'm still
GB> > not sure if it should be GetSystemThemeType(), as proposed by New Pagodi,
GB> > or just IsSystemThemeDark() as you seem to be leaning to?
GB>
GB> I think using GetSystemThemeType() is the way to go.
I also prefer it for the same reasons you give, but if Stefan thinks that
even under current macOS it's better to check if the theme is dark or light
instead of explicitly checking if it's the dark theme or not, there might
be some good reason to choose the other approach. I'm not sure what it
would be, however, which is why I'm asking...
Regards,
VZ
GB> On 2019-04-09 1:12 p.m., Vadim Zeitlin wrote:
GB> > SC> so this could be encapsulated in a system function, to me
GB> > SC> wxSystemSettings first comes to mind
GB> >
GB> > OK, as both you and New Pagodi prefer this, let's go with it. I'm still
GB> > not sure if it should be GetSystemThemeType(), as proposed by New Pagodi,
GB> > or just IsSystemThemeDark() as you seem to be leaning to?
GB>
GB> I think using GetSystemThemeType() is the way to go.
I also prefer it for the same reasons you give, but if Stefan thinks that
even under current macOS it's better to check if the theme is dark or light
instead of explicitly checking if it's the dark theme or not, there might
be some good reason to choose the other approach. I'm not sure what it
would be, however, which is why I'm asking...
Regards,
VZ
Stefan Csomor
Apr 10, 2019, 4:20:52 AM4/10/19
to wx-...@googlegroups.com
Hi
Am 09.04.19, 20:12 schrieb "Vadim Zeitlin" <wx-...@googlegroups.com im Auftrag von va...@wxwidgets.org>:
On Tue, 9 Apr 2019 17:23:46 +0000 Stefan Csomor wrote:
SC> the thing is that there are several elements involved to decide whether
SC> the app runs really in certain mode, wxOSXEffectiveAppearanceSetter
SC> makes sure, the current appearance is correct, then colors are
SC> correctly resolved
Hi,
Thanks for the reply, but I don't really understand why is this needed,
i.e. when would the app effective appearance be different from the current
appearance? Is there any good reason to even allow this to happen?
NSAppearance.current is the appearance that is active on the current thread, any UI element may set this as it wants to, for a window it may be a composited appearance (there are examples of a darkAqua appearance window within a aqua NSApp in the presentation)
therefore when we want to resolve the NSColor to its rgb representation we must manually make sure this uses our NSApp.effectiveAppearance,
without it at least on the early 10.14 betas things didn't always work properly, so we used the approach mentioned in
https://developer.apple.com/videos/play/wwdc2018/218
SC> In the emulated statusbar we use the value of the red channel of a
SC> certain system color to determine whether we are really in dark mode
SC>
SC> wxColour bg = wxSystemSettings::GetColour(wxSYS_COLOUR_APPWORKSPACE);
SC>
SC> if ( bg.Red() < 128 )
SC> {
SC> // dark mode appearance
This is more compatible with "is using dark theme" approach rather than
"is using the system dark mode" approach. It could be a better idea or not,
but I'm a bit surprised that you recommend doing it like this because
everything I found during my (admittedly brief) web search seemed to
recommend checking "AppleInterfaceStyle" value. Are the situations in which
these 2 methods would yield different results?
it depends whether you want to find out which name the appearance our app in use has or whether it renders the background darker.
In the past there have been appearance managers that allowed you to customize the appearance,
If we need the name then actually I'd suggest using
NSAppearanceName appearanceName = [[NSApp effectiveAppearance] name];
which on my machine gives NSAppearanceNameDarkAqua or NSAppearanceNameAqua, and I don't think at the app level this is already is already composited, but if we must make sure and want to decide which of the 'standard' appearances it is we could use this recommended approach
NSAppearanceName appearanceName = [[NSApp effectiveAppearance] bestMatchFromAppearancesWithNames :@[ NSAppearanceNameAqua, NSAppearanceNameDarkAqua];
if ([appearanceName isEqualToString:NSAppearanceNameDarkAqua]) {
// use dark color
SC> so this could be encapsulated in a system function, to me
SC> wxSystemSettings first comes to mind
OK, as both you and New Pagodi prefer this, let's go with it. I'm still
not sure if it should be GetSystemThemeType(), as proposed by New Pagodi,
or just IsSystemThemeDark() as you seem to be leaning to?
it may be wise to encapsulate both, I think type should rather be a string than an enum - and for rendering the darkness my be more relevant than the precise appearance
SC> > And finally I also think that it could be useful to send a
SC> > wxSysColourChangedEvent when the mode changes as I believe that
SC> > applications are supposed to react to this dynamically, i.e. switching
SC> > to/from dark mode shouldn't require a restart. This could be implemented by
SC> > reacting to (also undocumented) AppleInterfaceThemeChangedNotification,
SC> > according to what I saw, but any comments about this would be welcome as
SC> > well, of course.
SC>
SC> this is already the case (at least if there is a toplevel window),
SC> reacting to changes of effectiveAppearance happens in nonownedwnd.mm
SC> lines 627ff.
Ah, thanks, I've totally missed this. We could just set a flag in the
event generated there telling that it notifies about the whole theme change
then. Or maybe even this is superfluous...
Actually I'd think if the sys colors are changed in whatever way the handling is probably the same ? but if it may differ, then we might add a reason, or did I misunderstand ?
Thanks,
Stefan
Am 09.04.19, 20:12 schrieb "Vadim Zeitlin" <wx-...@googlegroups.com im Auftrag von va...@wxwidgets.org>:
On Tue, 9 Apr 2019 17:23:46 +0000 Stefan Csomor wrote:
SC> the thing is that there are several elements involved to decide whether
SC> the app runs really in certain mode, wxOSXEffectiveAppearanceSetter
SC> makes sure, the current appearance is correct, then colors are
SC> correctly resolved
Hi,
Thanks for the reply, but I don't really understand why is this needed,
i.e. when would the app effective appearance be different from the current
appearance? Is there any good reason to even allow this to happen?
therefore when we want to resolve the NSColor to its rgb representation we must manually make sure this uses our NSApp.effectiveAppearance,
without it at least on the early 10.14 betas things didn't always work properly, so we used the approach mentioned in
https://developer.apple.com/videos/play/wwdc2018/218
SC> In the emulated statusbar we use the value of the red channel of a
SC> certain system color to determine whether we are really in dark mode
SC>
SC> wxColour bg = wxSystemSettings::GetColour(wxSYS_COLOUR_APPWORKSPACE);
SC>
SC> if ( bg.Red() < 128 )
SC> {
SC> // dark mode appearance
This is more compatible with "is using dark theme" approach rather than
"is using the system dark mode" approach. It could be a better idea or not,
but I'm a bit surprised that you recommend doing it like this because
everything I found during my (admittedly brief) web search seemed to
recommend checking "AppleInterfaceStyle" value. Are the situations in which
these 2 methods would yield different results?
In the past there have been appearance managers that allowed you to customize the appearance,
If we need the name then actually I'd suggest using
NSAppearanceName appearanceName = [[NSApp effectiveAppearance] name];
which on my machine gives NSAppearanceNameDarkAqua or NSAppearanceNameAqua, and I don't think at the app level this is already is already composited, but if we must make sure and want to decide which of the 'standard' appearances it is we could use this recommended approach
NSAppearanceName appearanceName = [[NSApp effectiveAppearance] bestMatchFromAppearancesWithNames :@[ NSAppearanceNameAqua, NSAppearanceNameDarkAqua];
if ([appearanceName isEqualToString:NSAppearanceNameDarkAqua]) {
// use dark color
SC> so this could be encapsulated in a system function, to me
SC> wxSystemSettings first comes to mind
OK, as both you and New Pagodi prefer this, let's go with it. I'm still
not sure if it should be GetSystemThemeType(), as proposed by New Pagodi,
or just IsSystemThemeDark() as you seem to be leaning to?
SC> > And finally I also think that it could be useful to send a
SC> > wxSysColourChangedEvent when the mode changes as I believe that
SC> > applications are supposed to react to this dynamically, i.e. switching
SC> > to/from dark mode shouldn't require a restart. This could be implemented by
SC> > reacting to (also undocumented) AppleInterfaceThemeChangedNotification,
SC> > according to what I saw, but any comments about this would be welcome as
SC> > well, of course.
SC>
SC> this is already the case (at least if there is a toplevel window),
SC> reacting to changes of effectiveAppearance happens in nonownedwnd.mm
SC> lines 627ff.
Ah, thanks, I've totally missed this. We could just set a flag in the
event generated there telling that it notifies about the whole theme change
then. Or maybe even this is superfluous...
Thanks,
Stefan
Vadim Zeitlin
Apr 10, 2019, 12:30:13 PM4/10/19
to wx-...@googlegroups.com
On Wed, 10 Apr 2019 08:20:48 +0000 Stefan Csomor wrote:
SC> NSAppearance.current is the appearance that is active on the current
SC> thread, any UI element may set this as it wants to, for a window it may
SC> be a composited appearance (there are examples of a darkAqua appearance
SC> window within a aqua NSApp in the presentation) therefore when we want
SC> to resolve the NSColor to its rgb representation we must manually make
SC> sure this uses our NSApp.effectiveAppearance, without it at least on
SC> the early 10.14 betas things didn't always work properly, so we used
SC> the approach mentioned in
SC>
SC> https://developer.apple.com/videos/play/wwdc2018/218
Sorry, I didn't have time to watch the video, so maybe I'm annoying you
with the questions already answered in it, but I'm still missing something
fundamental here: when is NSAppearance.current changed? Shouldn't it be
done by the window which wants to use the non-default appearance only while
it's repainting itself? And, if so, wouldn't it actually make sense for
wxSystemSettings::GetColour() to return the colour appropriate for this
window, rather than the global application value, _if_ it's called while
this window is being repainted?
SC> SC> In the emulated statusbar we use the value of the red channel of a
SC> SC> certain system color to determine whether we are really in dark mode
SC> This is more compatible with "is using dark theme" approach rather than
SC> "is using the system dark mode" approach. It could be a better idea or not,
SC> but I'm a bit surprised that you recommend doing it like this because
SC> everything I found during my (admittedly brief) web search seemed to
SC> recommend checking "AppleInterfaceStyle" value. Are the situations in which
SC> these 2 methods would yield different results?
SC>
SC> it depends whether you want to find out which name the appearance our
SC> app in use has or whether it renders the background darker.
Well, that's the question, isn't it... I was under impression that under
10.14 there were just 2 appearances: light and dark. And, of course, both
approaches work equally well for just 2 of them. But I also thought that
perhaps Apple might add some other appearance in a later version and then
we'd have to recognize it as well and IsSystemThemeDark() won't be enough
for doing it. Of course, I have absolutely no idea about how likely this
is...
SC> there have been appearance managers that allowed you to customize the
SC> appearance,
SC>
SC> If we need the name then actually I'd suggest using
SC>
SC> NSAppearanceName appearanceName = [[NSApp effectiveAppearance] name];
SC>
SC> which on my machine gives NSAppearanceNameDarkAqua or NSAppearanceNameAqua, and I don't think at the app level this is already is already composited, but if we must make sure and want to decide which of the 'standard' appearances it is we could use this recommended approach
SC>
SC> NSAppearanceName appearanceName = [[NSApp effectiveAppearance] bestMatchFromAppearancesWithNames :@[ NSAppearanceNameAqua, NSAppearanceNameDarkAqua];
SC>
SC> if ([appearanceName isEqualToString:NSAppearanceNameDarkAqua]) {
SC> // use dark color
I've seen several mentions of this approach not working on some early
10.14 versions, but if you think it's fine to use it now, let's do it like
this.
SC> SC> so this could be encapsulated in a system function, to me
SC> SC> wxSystemSettings first comes to mind
SC>
SC> OK, as both you and New Pagodi prefer this, let's go with it. I'm still
SC> not sure if it should be GetSystemThemeType(), as proposed by New Pagodi,
SC> or just IsSystemThemeDark() as you seem to be leaning to?
SC>
SC> it may be wise to encapsulate both, I think type should rather be a
SC> string than an enum - and for rendering the darkness my be more
SC> relevant than the precise appearance
I dislike string-typed APIs... If we want to do it like this, it would
have to be an object, with GetName() and IsDark() methods. Or would this be
going too far for not much gain? OTOH, it's not like creating a class costs
a lot neither.
So I'm probably going to end up doing it like this, with new wxSystemTheme
class.
Any last minute comments/suggestions/better name proposals?
Thanks!
VZ
SC> NSAppearance.current is the appearance that is active on the current
SC> thread, any UI element may set this as it wants to, for a window it may
SC> be a composited appearance (there are examples of a darkAqua appearance
SC> window within a aqua NSApp in the presentation) therefore when we want
SC> to resolve the NSColor to its rgb representation we must manually make
SC> sure this uses our NSApp.effectiveAppearance, without it at least on
SC> the early 10.14 betas things didn't always work properly, so we used
SC> the approach mentioned in
SC>
SC> https://developer.apple.com/videos/play/wwdc2018/218
Sorry, I didn't have time to watch the video, so maybe I'm annoying you
with the questions already answered in it, but I'm still missing something
fundamental here: when is NSAppearance.current changed? Shouldn't it be
done by the window which wants to use the non-default appearance only while
it's repainting itself? And, if so, wouldn't it actually make sense for
wxSystemSettings::GetColour() to return the colour appropriate for this
window, rather than the global application value, _if_ it's called while
this window is being repainted?
SC> SC> In the emulated statusbar we use the value of the red channel of a
SC> SC> certain system color to determine whether we are really in dark mode
SC> SC>
SC> SC> wxColour bg = wxSystemSettings::GetColour(wxSYS_COLOUR_APPWORKSPACE);
SC> SC>
SC> SC> if ( bg.Red() < 128 )
SC> SC> {
SC> SC> wxColour bg = wxSystemSettings::GetColour(wxSYS_COLOUR_APPWORKSPACE);
SC> SC>
SC> SC> if ( bg.Red() < 128 )
SC> SC> // dark mode appearance
SC>
SC> This is more compatible with "is using dark theme" approach rather than
SC> "is using the system dark mode" approach. It could be a better idea or not,
SC> but I'm a bit surprised that you recommend doing it like this because
SC> everything I found during my (admittedly brief) web search seemed to
SC> recommend checking "AppleInterfaceStyle" value. Are the situations in which
SC> these 2 methods would yield different results?
SC>
SC> it depends whether you want to find out which name the appearance our
SC> app in use has or whether it renders the background darker.
Well, that's the question, isn't it... I was under impression that under
10.14 there were just 2 appearances: light and dark. And, of course, both
approaches work equally well for just 2 of them. But I also thought that
perhaps Apple might add some other appearance in a later version and then
we'd have to recognize it as well and IsSystemThemeDark() won't be enough
for doing it. Of course, I have absolutely no idea about how likely this
is...
SC> there have been appearance managers that allowed you to customize the
SC> appearance,
SC>
SC> If we need the name then actually I'd suggest using
SC>
SC> NSAppearanceName appearanceName = [[NSApp effectiveAppearance] name];
SC>
SC> which on my machine gives NSAppearanceNameDarkAqua or NSAppearanceNameAqua, and I don't think at the app level this is already is already composited, but if we must make sure and want to decide which of the 'standard' appearances it is we could use this recommended approach
SC>
SC> NSAppearanceName appearanceName = [[NSApp effectiveAppearance] bestMatchFromAppearancesWithNames :@[ NSAppearanceNameAqua, NSAppearanceNameDarkAqua];
SC>
SC> if ([appearanceName isEqualToString:NSAppearanceNameDarkAqua]) {
SC> // use dark color
I've seen several mentions of this approach not working on some early
10.14 versions, but if you think it's fine to use it now, let's do it like
this.
SC> SC> so this could be encapsulated in a system function, to me
SC> SC> wxSystemSettings first comes to mind
SC>
SC> OK, as both you and New Pagodi prefer this, let's go with it. I'm still
SC> not sure if it should be GetSystemThemeType(), as proposed by New Pagodi,
SC> or just IsSystemThemeDark() as you seem to be leaning to?
SC>
SC> it may be wise to encapsulate both, I think type should rather be a
SC> string than an enum - and for rendering the darkness my be more
SC> relevant than the precise appearance
I dislike string-typed APIs... If we want to do it like this, it would
have to be an object, with GetName() and IsDark() methods. Or would this be
going too far for not much gain? OTOH, it's not like creating a class costs
a lot neither.
So I'm probably going to end up doing it like this, with new wxSystemTheme
class.
Any last minute comments/suggestions/better name proposals?
Thanks!
VZ
Stefan Csomor
Apr 11, 2019, 5:41:34 AM4/11/19
to wx-...@googlegroups.com
Am 10.04.19, 18:30 schrieb "Vadim Zeitlin" <wx-...@googlegroups.com im Auftrag von va...@wxwidgets.org>:
On Wed, 10 Apr 2019 08:20:48 +0000 Stefan Csomor wrote:
SC> NSAppearance.current is the appearance that is active on the current
SC> thread, any UI element may set this as it wants to, for a window it may
SC> be a composited appearance (there are examples of a darkAqua appearance
SC> window within a aqua NSApp in the presentation) therefore when we want
SC> to resolve the NSColor to its rgb representation we must manually make
SC> sure this uses our NSApp.effectiveAppearance, without it at least on
SC> the early 10.14 betas things didn't always work properly, so we used
SC> the approach mentioned in
SC>
SC> https://developer.apple.com/videos/play/wwdc2018/218
Sorry, I didn't have time to watch the video, so maybe I'm annoying you
with the questions already answered in it, but I'm still missing something
fundamental here: when is NSAppearance.current changed? Shouldn't it be
done by the window which wants to use the non-default appearance only while
it's repainting itself? And, if so, wouldn't it actually make sense for
wxSystemSettings::GetColour() to return the colour appropriate for this
window, rather than the global application value, _if_ it's called while
this window is being repainted?
if we'd allow that yes, but then wxSystemSettings would be the right API anymore IMHO and
we'd have to make sure, things really get painted when the system has setup things, not out-of-band
So at the moment I'd like to have the typical setup working, and that's the way to isolate us from
any native subwindows, system dialogs etc messing with our main appearance
SC> SC> so this could be encapsulated in a system function, to me
SC> SC> wxSystemSettings first comes to mind
SC>
SC> OK, as both you and New Pagodi prefer this, let's go with it. I'm still
SC> not sure if it should be GetSystemThemeType(), as proposed by New Pagodi,
SC> or just IsSystemThemeDark() as you seem to be leaning to?
SC>
SC> it may be wise to encapsulate both, I think type should rather be a
SC> string than an enum - and for rendering the darkness my be more
SC> relevant than the precise appearance
I dislike string-typed APIs... If we want to do it like this, it would
have to be an object, with GetName() and IsDark() methods. Or would this be
going too far for not much gain? OTOH, it's not like creating a class costs
a lot neither.
So I'm probably going to end up doing it like this, with new wxSystemTheme
class.
Any last minute comments/suggestions/better name proposals?
Thanks,
Stefan
Reply all
Reply to author
Forward
0 new messages