MacOS Auto settings is treated as dark mode

[eugene-stativka]

Thank you for your great job! I've tried 1.1.0-pre on MacOS 10.15.4 and it seems like Auto appearance setting is treated as dark mode even if it is not a late evening and light mode is automatically set by the operating system. Can you please check?

[weisJ]

I'll have to look into it. I do not have a system with macOS installed myself. Basically the responsible code for the check is the following:

NSString *interfaceStyle = [[NSUserDefaults standardUserDefaults] stringForKey:@"AppleInterfaceStyle"];
// interfaceStyle can be nil (light mode) or "Dark" (dark mode).
BOOL isDark = [VALUE_DARK caseInsensitiveCompare:interfaceStyle] == NSOrderedSame;
BOOL switchesAutomatically = [[NSUserDefaults standardUserDefaults] boolForKey:@"AppleInterfaceStyleSwitchesAutomatically"];
if (switchesAutomatically) {
    // If switchesAutomatically == YES the roles of "Dark" and nil are changed.
    return (jboolean) !isDark;
}

If you run this on your machine does it yield the correct value?

[weisJ]

After doing some remote testing with a friends machine it seems as if the value of AppleInterfaceStyleSwitchesAutomatically can be ignored and AppleInterfaceStyle actually always represents the actual value.

[weisJ]

Could you try out if the new pre-release works as expected?

[eugene-stativka]

Could you try out if the new pre-release works as expected?

Sure, I will do it first thing in the morning.

[eugene-stativka]

In this release this issue is fixed. Thanks!

[weisJ]

I did some more research and apparently the Catalina Auto option is not that simple. If switching manually to it the properties are set correctly but if it switches by passing the time threshold the setting isn't picked up correctly.

[weisJ]

I'm kind of getting conflicting information. For one there is this issue. The propsed solution is to use NSApp.effectiveAppearance. However NSApp.effectiveAppearance is always NSAppearanceAqua as the library isn't really attached to a valid application.

This issue also highlights a possible issue when powering off in dark mode and turning back in during daytime. I'll have to do more testing but as long as there is no power off involved it works.

[weisJ]

@eugene-stativka Do you experience errors between restarts/sleep mode? However I suspect for now this issue is neglectable as I doubt a lot of people keep IDEA open between system restarts.

[eugene-stativka]

@eugene-stativka Do you experience errors between restarts/sleep mode?

So far, no but maybe I haven't covered all edge cases yet. I will let you know if I notice something

[bric3]

For now the plugin behaves well.

I'm using NightOwl to control the dark mode. I've tried :

• [x] scheduled mode
• [x] manual
• [x] sunrise / sunset
• [x] closing the lid / sleep

IntelliJ 2020.1

❯ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.15.4
BuildVersion:   19E287

[weisJ]

@bric3 good to know 👍 I have released the current latest pre-release (should be available in 2/3 days). If any issues arise this issue can be reopened.

[bric3]

I've set NightOwl mode sunrise / sunset, with lid closed in-between. Looks good !

[bric3]

Actually I think I encountered a bug.

• Use sunset mode in nightowl
• Use the laptop after the sunset, ie in dark mode
• Close the lid
• Open the lid after the sunrise, the UI is light
• I needed to test some other stuff, so I switched manually to Dark appearance, but IJ didn't respond to that change. Restarting is the only option.

Maybe I should log that in another issue.

[weisJ]

That is exactly the possible scenario that would break it I had in mind. I has to do with a weird behaviour of how auto is implemented. Generally there is the value "AppleInterfaceStyle" that is either nil or "Dark" depending of the mode. But in some scenarios their semantic is swapped. The saver approach would be to read NSApp.effectiveAppearance but as I have mentioned before this always return the same value. I guess this has to do with the dll running outside of a valid cocoa application.