Detecting changes between dark and light mode on Mac OS

Detecting changes between dark and light mode on Mac OS

[Daphne Preston-Kendal]

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

Hello,

I've attempted to implement support for detecting and responding to
changes between system dark and light mode on Mac OS.

This patch makes it so that the ns-appearance parameter of a frame is
always bound — if it isn't set by the user, it's set to 'dark or
'light depending on the operating system's default setting. It also
listens for changes in the systemwide appearance, changes the
ns-appearance on all frames when that happens, and runs a new hook,
ns-dark-mode-change-hook. (It's still possible to set ns-appearance on
a frame-by-frame basis, but such changes will be overridden the next
time the systemwide appearance changes.)

This enables users to automatically set Emacs to change their theme
when the system changes from dark to light, for example. (Since
Mac OS 10.15, there is a mode in the system which automatically
changes to dark mode in the evening and light mode during the day;
various third-party utilities existed to provide similar behaviour
before 10.15. So this helps Emacs follow that automatic change,
for example.)

This is my first Emacs patch, and also the first time I've written
Objective-C in probably ten years. So there are probably still
gremlins lurking here and there, and I'd appreciate feedback!

Many thanks


Daphne Preston-Kendal


[-- Attachment #2: 0001-auto-detection-of-ns-appearance-and-an-ns-dark-mode-.patch --]
[-- Type: application/octet-stream, Size: 4845 bytes --]

From 813b66cff906bc39b7615b7ca71689da3388029c Mon Sep 17 00:00:00 2001
From: Daphne Preston-Kendal <git@dpk.io>
Date: Tue, 9 Mar 2021 13:05:13 +0100
Subject: [PATCH] auto-detection of ns-appearance, and an
 ns-dark-mode-change-hook

---
 src/nsfns.m  | 10 +++++++++-
 src/nsterm.m | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/src/nsfns.m b/src/nsfns.m
index 5c4cc915e7..fc73725226 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -1284,7 +1284,15 @@ Turn the input menu (an NSMenu) into a lisp list for tracking on lisp side.
   else if (EQ (tem, Qlight))
     FRAME_NS_APPEARANCE (f) = ns_appearance_aqua;
   else
-    FRAME_NS_APPEARANCE (f) = ns_appearance_system_default;
+    {
+      tem = [[[NSApp effectiveAppearance]
+               bestMatchFromAppearancesWithNames:@[
+                                                   NSAppearanceNameAqua,
+                                                   NSAppearanceNameDarkAqua
+                                                   ]
+              ] isEqualToString:NSAppearanceNameDarkAqua] ? Qdark : Qlight;
+      FRAME_NS_APPEARANCE (f) = (tem == Qdark ? ns_appearance_vibrant_dark : ns_appearance_aqua);
+    }
   store_frame_param (f, Qns_appearance,
                      (!NILP (tem) && !EQ (tem, Qunbound)) ? tem : Qnil);
 
diff --git a/src/nsterm.m b/src/nsterm.m
index bf175bbd18..e0632e347e 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -2207,6 +2207,14 @@ so some key presses (TAB) are swallowed by the system.  */
 #endif /* MAC_OS_X_VERSION_MAX_ALLOWED >= 101000 */
 }
 
+void
+ns_update_system_appearance (struct frame *f, Lisp_Object new_value)
+{
+#if MAC_OS_X_VERSION_MAX_ALLOWED >= 101000
+  store_frame_param (f, Qns_appearance, new_value);
+#endif /* MAC_OS_X_VERSION_MAX_ALLOWED >= 101000 */
+}
+
 void
 ns_set_transparent_titlebar (struct frame *f, Lisp_Object new_value,
                              Lisp_Object old_value)
@@ -5926,6 +5934,15 @@ - (void)applicationDidFinishLaunching: (NSNotification *)notification
 	 object:nil];
 #endif
 
+#ifdef NS_IMPL_COCOA
+  [[NSDistributedNotificationCenter defaultCenter]
+    addObserver:self
+       selector:@selector(darkModeDidChange:)
+           name:@"AppleInterfaceThemeChangedNotification"
+         object:nil
+   ];
+#endif
+
 #ifdef NS_IMPL_COCOA
   /* Some functions/methods in CoreFoundation/Foundation increase the
      maximum number of open files for the process in their first call.
@@ -5964,6 +5981,32 @@ - (void)antialiasThresholdDidChange:(NSNotification *)notification
 #endif
 }
 
+- (void)darkModeDidChange:(NSNotification *)notification
+{
+#ifdef NS_IMPL_COCOA
+  NSTRACE ("[EmacsApp darkModeDidChange:]");
+
+  Lisp_Object new_value = [[[self effectiveAppearance]
+                             bestMatchFromAppearancesWithNames:@[
+                                                                 NSAppearanceNameAqua,
+                                                                 NSAppearanceNameDarkAqua
+                                                                 ]
+                            ] isEqualToString:NSAppearanceNameDarkAqua] ? Qlight : Qdark; /* this is backwards; i have no idea why */
+
+  Lisp_Object tail, frame;
+  FOR_EACH_FRAME (tail, frame)
+    {
+      struct frame *f = XFRAME (frame);
+      EmacsView *view = (EmacsView *)FRAME_NS_VIEW (f);
+      EmacsWindow *window = (EmacsWindow *)[view window];
+      ns_update_system_appearance (f, new_value);
+      ns_set_appearance (f, new_value,
+                         (new_value == Qdark ? Qlight : Qdark));
+    }
+
+  run_hook (Qns_dark_mode_changed_hook);
+#endif
+}
 
 /* Termination sequences:
     C-x C-c:
@@ -9790,7 +9833,7 @@ - (CGContextRef) getContext
   IOSurfaceRef surface = NULL;
 
   NSTRACE ("[EmacsSurface getContextWithSize:]");
-  NSTRACE_MSG (@"IOSurface count: %lu", [cache count] + (lastSurface ? 1 : 0));
+  // NSTRACE_MSG (@"IOSurface count: %lu", [cache count] + (lastSurface ? 1 : 0));
 
   for (id object in cache)
     {
@@ -10199,6 +10242,11 @@ Nil means use fullscreen the old (< 10.7) way.  The old way works better with
 This variable is ignored on Mac OS X < 10.7 and GNUstep.  */);
   ns_use_srgb_colorspace = YES;
 
+  DEFSYM (Qns_dark_mode_changed_hook, "ns-dark-mode-changed-hook");
+
+  DEFVAR_LISP ("ns-dark-mode-changed-hook", Vns_dark_mode_changed_hook,
+               doc: /* Hook run when the Mac OS system-wide UI theme changes from dark to light or vice versa. */);
+
   DEFVAR_BOOL ("ns-use-mwheel-acceleration",
                ns_use_mwheel_acceleration,
      doc: /* Non-nil means use macOS's standard mouse wheel acceleration.
-- 
2.24.3 (Apple Git-128)

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

[Daphne Preston-Kendal]

Hello there,

Not to pester, more to enquire: I submitted this patch nearly two
weeks ago and still haven’t heard any feedback. I submitted it here
because the Emacs manual says ‘If your patch is not complete and you
think it needs more discussion, you might want to send it to
emacs-devel@gnu.org instead.’
<https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html>

I *think* my patch is complete, but out of inexperience I’m
unsure. (For instance, I know I shouldn’t break support for GNUstep or
any previous Mac OS version going back to 10.6, but I don’t have any
way to test that, nor sufficient experience with the relevant
platforms to know if the changes I made are even likely to cause
problems in those departments, though I don’t think they would.) Is
there a better place than this to send it to get the attention of the
people who work on Cocoa Emacs and can help more directly with this
question? Should I just send it directly to bug-gnu-emacs@gnu.org?

Many thanks again,


Daphne Preston-Kendal

> On 9 Mar 2021, at 14:23, Daphne Preston-Kendal <dpk@nonceword.org> wrote:
> 
> Hello,
> 
> I've attempted to implement support for detecting and responding to
> changes between system dark and light mode on Mac OS.
> [snip]
> Many thanks
> 
> 
> Daphne Preston-Kendal
> 
> <0001-auto-detection-of-ns-appearance-and-an-ns-dark-mode-.patch>

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

[Alan Third]

On Sat, Mar 20, 2021 at 05:51:26PM +0100, Daphne Preston-Kendal wrote:
> Hello there,
> 
> Not to pester, more to enquire: I submitted this patch nearly two
> weeks ago and still haven’t heard any feedback. I submitted it here
> because the Emacs manual says ‘If your patch is not complete and you
> think it needs more discussion, you might want to send it to
> emacs-devel@gnu.org instead.’
> <https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html>
> 
> I *think* my patch is complete, but out of inexperience I’m
> unsure. (For instance, I know I shouldn’t break support for GNUstep or
> any previous Mac OS version going back to 10.6, but I don’t have any
> way to test that, nor sufficient experience with the relevant
> platforms to know if the changes I made are even likely to cause
> problems in those departments, though I don’t think they would.) Is
> there a better place than this to send it to get the attention of the
> people who work on Cocoa Emacs and can help more directly with this
> question? Should I just send it directly to bug-gnu-emacs@gnu.org?

Sorry, it fell through the cracks.

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.

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.
-- 
Alan Third

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

[Lars Ingebrigtsen]

Daphne Preston-Kendal <dpk@nonceword.org> writes:

> Not to pester, more to enquire: I submitted this patch nearly two
> weeks ago and still haven’t heard any feedback.

[...]

> Is there a better place than this to send it to get the attention of
> the people who work on Cocoa Emacs and can help more directly with
> this question? Should I just send it directly to
> bug-gnu-emacs@gnu.org?

Sorry about the lack of feedback here -- yes, in general, it's better to
send patches to the issue tracker (i.e., bug-gnu-emacs@gnu.org) than to
emacs-devel, because patches have a tendency to get lost on emacs-devel.

I'm don't use Macos much myself, so I can't really comment on the
Macos-specific parts of the patch, but:

> +  DEFSYM (Qns_dark_mode_changed_hook, "ns-dark-mode-changed-hook");
> +
> +  DEFVAR_LISP ("ns-dark-mode-changed-hook", Vns_dark_mode_changed_hook,
> +               doc: /* Hook run when the Mac OS system-wide UI theme changes from dark to light or vice versa. */);
> +

In Emacs, we generally don't add features that work on non-free
operating systems only.  So this should instead be a general
`dark-mode-changed-hook' feature, with a specific implementation on
GNU/Linux, Macos, etc.

And we should definitely have a feature in Emacs to respond to dark-mode
changes across the board.  I seem to recall there being some discussion
about this in the past, but I can't find it now.  Does anybody remember
where that went?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Daphne Preston-Kendal]

On 21 Mar 2021, at 08:01, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Sorry about the lack of feedback here -- yes, in general, it's better to
> send patches to the issue tracker (i.e., bug-gnu-emacs@gnu.org) than to
> emacs-devel, because patches have a tendency to get lost on emacs-devel.

Okay, thanks — I’ll try there directly.

> In Emacs, we generally don't add features that work on non-free
> operating systems only.  So this should instead be a general
> `dark-mode-changed-hook' feature, with a specific implementation on
> GNU/Linux, Macos, etc.
> 
> And we should definitely have a feature in Emacs to respond to dark-mode
> changes across the board.  I seem to recall there being some discussion
> about this in the past, but I can't find it now.  Does anybody remember
> where that went?

Okay, well, if there are plans to support similar functionality
cross-platform, surely it’s okay to add it just for Mac OS for now?
There’s already quite a few Mac OS specific features in nsterm.m and
nsfns.m. The ns-appearance property on frames, which already provides
a limited form of integration with this Mac OS feature (you can set
the theme to light or dark on a per-frame basis, but it doesn’t tell
you what the system sets it to by default, which my patch fixes) is
one of them!

I don’t know how well standardized the events (and event systems) for
changes in system theme are in other Unix desktop environments, but if
someone does manage to make it work cross-platform, then the
ns-dark-mode-changed-hook from this patch could simply be made an
alias to a new, cross-platform dark-mode-changed-hook. (Though note
that the inspection of which theme was just activated, dark or light,
which typical functions attached to ns-dark-mode-hook would have to
do, also depends on the Mac OS-specific ns-appearance frame property.)

Or is your suggestion that I simply rename this hook to
dark-mode-changed-hook without the ns- prefix, notwithstanding that it
doesn’t currently work on any platform other than Mac OS?

> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no

Many thanks,


Daphne Preston-Kendal

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

[Daphne Preston-Kendal]

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

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

[Lars Ingebrigtsen]

Daphne Preston-Kendal <dpk@nonceword.org> writes:

> Okay, well, if there are plans to support similar functionality
> cross-platform, surely it’s okay to add it just for Mac OS for now?
> There’s already quite a few Mac OS specific features in nsterm.m and
> nsfns.m. The ns-appearance property on frames, which already provides
> a limited form of integration with this Mac OS feature (you can set
> the theme to light or dark on a per-frame basis, but it doesn’t tell
> you what the system sets it to by default, which my patch fixes) is
> one of them!

Some non-free system specific things have snuck in over the years, but
we try not to.

> Or is your suggestion that I simply rename this hook to
> dark-mode-changed-hook without the ns- prefix, notwithstanding that it
> doesn’t currently work on any platform other than Mac OS?

No, the project policy is that features like this should also have an
implementation on free systems, too, before support for non-free systems
are added, unfortunately.

So support for dark mode on GNU/Linux has to be added first (or at the
same time).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Matt Armstrong]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> And we should definitely have a feature in Emacs to respond to dark-mode
> changes across the board.  I seem to recall there being some discussion
> about this in the past, but I can't find it now.  Does anybody remember
> where that went?

Lars, were you thinking of this thread?

    Stefan Monnier <monnier@iro.umontreal.ca> (November 20)
    Subject: night-mode?
    To: emacs-devel@gnu.org
    Date: Fri, 20 Nov 2020 16:25:35 -0500

    https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00912.html

It looks like Stefan stopped working on it, but it looked promising to
me.  He didn't hook it into the system theme change mechanism I point
out below, but that isn't too much of a leap.

It seems to me that this feature isn't a really about "light vs. dark",
but instead it is more about dynamically responding to changes in the
system theme.  Preferably, any change.

I notice that Emacs does have a Lisp level hook for theme changes today,
currently used by GTK.  See
`dynamic-setting-handle-config-changed-event' in dynamic-setting.el, and
the corresponding call to 'kbd_buffer_store_event' in 'style-changed' in
gtkutil.c.  Today, it seems like GTK responds to the system theme in two
ways:

 - changing the GTK Mono font changes Emacs' default font (not in any
   current frames, but in newly created ones)
 - changing the GTK theme changes the faces used for regions (the
   'region' face, etc., by way of 'gtk_selection_bg_color' and
   'gtk_selection_fg_color' colors).

Daphne, I would suggest hooking into dynamic-setting.el, which implement
the above.  That seems much better than adding something that is similar
but different than what is already in place for GTK.

Today, the dynamic-setting.el stuff invalidates font caches on theme
change but doesn't mess with frames at all.  That is all it needs to do
to support the features I list above.  Responding to theme changes more
dynamically, e.g. by changing the whole Emacs theme, is closer to the
things discussed in Stefan's thread linked above.  It should be about as
easy to design this in a way that works the same across GUI toolkits as
it is to do it for ns only.

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

[chad]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

The conversations that I recall from around 5-10 years ago draw a fuzzy
line around this topic (which seems appropriate). On the one hand, Emacs
(GNU, the FSF, etc.) don't want to encourage people to use non-free systems
by making Emacs "better" on those systems, and on the other hand, there's a
recognition that the "baseline system support" for various OS's varies,
including across the free/non-free boundary. Combine that with the reality
that volunteer software is built by developers scratching itches, and
sometimes the non-free support will drift ahead for a bit.

For macos specifically, there's been an additional wrinkle in GNUstep,
although that seems (from a fairly far remove, admittedly) to have become
more and more vestigial over time.

All that said: there is support inside emacs for switching between light
and dark modes, at least inside the (included) modus vivendi/operandi pair
of themes. This includes the ability to set up modus so that it is
configured for both light and dark modes, has a very simple switch between
the two, and has a way to automate the switch (based on a timer and/or DBUS
message, IIRC). In practical terms, I believe that it should be ok to
develop this support for macos now as a "baseline system support" feature
that is either present or very nearly present on Emacs regardless of
platform. In fact, it would be best if the macos support for recognizing
the system-level switch and hook into whatever modus uses.

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 1641 bytes --]

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

[Lars Ingebrigtsen]

Matt Armstrong <matt@rfc20.org> writes:

> Lars, were you thinking of this thread?
>
>     Stefan Monnier <monnier@iro.umontreal.ca> (November 20)
>     Subject: night-mode?
>     To: emacs-devel@gnu.org
>     Date: Fri, 20 Nov 2020 16:25:35 -0500
>
>     https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00912.html

Yup; that's the one, I think...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Stefan Monnier]

>> Lars, were you thinking of this thread?
>>
>>     Stefan Monnier <monnier@iro.umontreal.ca> (November 20)
>>     Subject: night-mode?
>>     To: emacs-devel@gnu.org
>>     Date: Fri, 20 Nov 2020 16:25:35 -0500
>>
>>     https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00912.html
>
> Yup; that's the one, I think...

Clearly, it needs improvement, tho.

IIRC the simplest was that it should be renamed to `dark-mode`.
Another was that it should enable/disable themes according to their
compatibility with dark or light mode.

Also the code included some FIXMEs which should be taken care of.


        Stefan

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

[chad]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

The update of the mac port for emacs 27.2 includes this
probably-interesting note:

*** New hook mac-effective-appearance-change-hook.
> Contributed by Peter Hardy.


It looks like the code is in mac-win.el, viewable here:
https://bitbucket.org/mituharu/emacs-mac/raw/a124e5d0ccb820095be99c78d51abfd36ee22d9b/lisp/term/mac-win.el

HTH,
~Chad

[-- Attachment #2: Type: text/html, Size: 679 bytes --]