Nswindow not updating
To accommodate this, I extend NSApplication to offer an identically named property: This method takes advantage of Dark Mode, so it doesn’t have to replicate any of the important, but slightly clumsy “best Match” code either.
Having these convenient methods at my fingertips has been a great aid because it allows me to quickly answer the high-level question of whether an appearance is dark or not, regardless of whether I’m implementing drawing code or making a higher-level semantic interpretation of the application’s user-facing appearance.
Here is a capsule summary to use as reference in the context of these articles: As you modify your code to respect the current or effective appearance, you will probably need to make high level assessments like “is this appearance light or dark?
” Because of the aforementioned complication that there are many types of NSAppearance, that they can be nested, etc., it’s not possible to simply compare the current appearance with a named appearance.
Instead, you use a method on NSAppearance designed to evaluate which high-level appearance it is most like.
This helper method is handy for working with NSAppearance instances, but in some contexts what I really want to know is bluntly: is this app running in dark mode or not?
Please do read the documentation in the MAAttached Window.h file; it’ll help you get the most out of the class.
Update: The source has been updated today (5pm GMT on Fri 5th Oct 2007), to fix a possible recursion bug due to the attached window registering for frame-change notifications on itself. We also now accept key (but not main) status by default, and have an implementation of -validate Menu Item: which passes off to either the window we’re attached to, or to super.
Take a look at the sample app to see more about how it works.
Download, as ever, from the Cocoa Source Code page.