Nice, wonder how this will work.
I imagine it will work pretty much how the dark mode of the NSStatusItem works. If you make native apps with native controls, I imagine it will already support it. Of course, you may need to provide dark mode appropriate images for certain buttons (as with NSStatusItem).
This will reveal overnight who uses non-native stuff in their dev tools and apps.
done properly, all icons for iOS applications should be gray-scale masks, and rendered as "templates", so you can use one image and display it as any color you wish.
I design all my iOS apps with a color template class, and the controls, views etc never refer to a "hard-coded" color
Here's how I imagine it to work. Exactly as 'Dark Mode' already works today, but with a system wide option, utilizing NSAppearance.
Which means that:
All of which can be done in native Xojo code.
In the current edition of http://xdevmag.com/ I have an article on going dark already. The second part will be in the next edition. I am planning to wipe my 2015 MacBook and install "Mojave" there so I can see if I need to make any changes to my article.
Here's the documentation on it.
I'll be taking a deeper look into in a moment (or many moments). Looks like there isn't much to change, unless you've already enabled a dark mode, that is :( Or draw custom controls :(
Helge, I guess without OS API calls it's not possible by default now. But I am sure Xojo will implement this sooner or later giving you a higher level built-in switch for it. Would be cool feature if this would work cross-platform in Linux too.
Apps linked against the macOS 10.14 SDK are assumed to support both appearance types unless they explicitly opt out.
Seems like we can hard code which appearance to use, but not automatically obtain it (yet).
If you want to experiment with Dark Mode, add the following code to the open event of your application. Don't forget to check and make sure that the app is running on 10.14 before you execute this code. THIS CODE WILL CRASH YOUR APPLICATION ON ANY OS VERSION BELOW 10.14
#if targetMacOS then declare function NSClassFromString lib "Cocoa" ( inClassName as CFStringRef ) as integer declare sub setAppearance lib "Cocoa" selector "setAppearance:" ( NSApplicationInstance as integer, NSAppearanceInstance as integer ) declare function sharedApplication lib "Cocoa" selector "sharedApplication" ( classRef as integer ) as integer declare function NSAppearanceNamed lib "Cocoa" selector "appearanceNamed:" ( NSAppearanceClass as integer, name as CFStringRef ) as integer setAppearance( sharedApplication( NSClassFromString( "NSApplication" ) ), _ NSAppearanceNamed( NSClassFromString( "NSAppearance" ), "NSAppearanceNameDarkAqua" ) ) #endif
However to get it to automatically adopt dark mode, is something that I'm still investigating.
@Sam R However to get it to automatically adopt dark mode, is something that I'm still investigating.
Xojo will need to link against the 10.14 SDK and that's it. "Apps linked against the macOS 10.14 SDK are assumed to support both appearance types unless they explicitly opt out." It's automatic after that. Of course, there's a ton of other work to do in our apps to properly support it but it's basically automatic if using native controls. If you want your app to disallow it, you add a key/value to Info.plist.
@Gavin S Xojo will need to link against the 10.14 SDK and that's it.
Yeah saw that earlier, I am fairly confident it ain't going to happen anytime soon... I'm still waiting for them to link against 10.11 so I no longer get warnings about Metal :)
Beside apart form it not being automatic and some controls not working, it's a heck of a lot nicer than the DarkVibrancyMode we had before. Far more consistent, & colorful too :)
Edit: I'm going to leave it for a while, the TextField issue might be a bug as there's quite a few visual glitches still. On a lighter note, it's already far more stable than any of betas of High Sierra, so that's promising.
@Sam R Beside apart form it not being automatic and some controls not working, it's a heck of a lot nicer than the DarkVibrancyMode we had before. Far more consistent, & colorful too :)
Agreed. A renaissance for VisualEffectViews – which means it would be great to have (text) controls supporting Vibrancy …