Re: Detecting changes between dark and light mode on Mac OS

[Daphne Preston-Kendal <dpk@nonceword.org>]

On 20 Mar 2021, at 18:52, Alan Third <alan@idiocy.org> wrote:

> I'm not sure about this patch purely on the grounds that the scrollbar
> colour Just Works with the Emacs theme in the current set up, but when
> you explicitly set light or dark it has to explicitly match the theme
> or it looks very strange. Even then the background is the wrong colour
> in themes that don't use white or black.

Hmm, I noticed (but didn’t bother fixing) a very similar bug with the
selection colour while writing this patch: it gets set once when Emacs
starts, but doesn’t get updated when the system theme changes. So if
you started Emacs when the system was in dark mode, then change to
light, you’ll be stuck with the dark mode selection colour, etc. (A
day or two later I noticed that Apple’s own Mail app has the exact
same bug with the selection colour borders for messages in a thread.)

Perhaps there’s a bunch of different colour/theme related appearance
changes that need to be automagically made when Emacs receives the
AppleInterfaceThemeChangedNotification event.

> Is that down to our choice of light and dark macOS themes? Perhaps
> there's a smarter way of setting the theme for various widgets?
> 
> Aside from that it looks OK to me. The only major changes I think I'd
> require are some #ifs to limit the new code to macOS 10.14+, but
> that's not a big problem.

Yes, good plan. I noticed that Emacs was using the
NSAppearanceNameVibrantDark before, which is presumably what the
menu-bar-only version of dark mode in Mac OSes 10.10 to 10.13 was
called? When I tested the effectiveAppearance against it, it always
thought *VibrantDark was light mode, so I used *DarkAqua in my patch.
Providing two versions, one for 10.10 to 10.13 with roughly the old
behaviour using *VibrantDark, and one for 10.14+ with the new
behaviour, seems like a decent plan.

> -- 
> Alan Third

Daphne Preston-Kendal