GNU bug report logs - #80001
[PATCH 1/1] Support `toolkit-theme-set-functions' on macOS

Previous Next

To reply to this bug, email your comments to 80001 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH 1/1] Support `toolkit-theme-set-functions' on macOS
Date: Sat, 13 Dec 2025 22:07:17 +0100

[Message part 1 (text/plain, inline)]

Hello,

this is a follow-up to bug#79776 (patch by Ahmed Khanzada, merged into
master with commit bc0f662573684919af7440b41531e9861a86ce6f), and the
improvements to it by Po Lu (commit
7550791287503ebc582c92841f6483032aa0b050).

The attached patch enables the `toolkit-theme-set-functions'
functionality on macOS 10.14+, too.


Hoping to have helped, and looking forward to your thoughts,

  --alexander

[0001-Support--toolkit-theme-set-functions'-on-macOS.patch (text/x-patch, attachment)]

Message #8 received at 80001 <at> debbugs.gnu.org (full text, mbox):

From: Stéphane Marks <shipmints <at> gmail.com>
To: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
Cc: 80001 <at> debbugs.gnu.org
Subject: Re: bug#80001: [PATCH 1/1] Support `toolkit-theme-set-functions' on
 macOS
Date: Sat, 13 Dec 2025 16:31:25 -0500

[Message part 1 (text/plain, inline)]

On Sat, Dec 13, 2025 at 4:08 PM Alexander Adolf via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:

> Hello,
>
> this is a follow-up to bug#79776 (patch by Ahmed Khanzada, merged into
> master with commit bc0f662573684919af7440b41531e9861a86ce6f), and the
> improvements to it by Po Lu (commit
> 7550791287503ebc582c92841f6483032aa0b050).
>
> The attached patch enables the `toolkit-theme-set-functions'
> functionality on macOS 10.14+, too.
>
>
> Hoping to have helped, and looking forward to your thoughts,
>

I have a vague recollection of this coming up in the last year or so.
Might be worth searching through the archives.

One thing I might change is to use notifications since this is a
system-wide effect.  For an example, look for
NSApplicationDidChangeScreenParametersNotification in nsterm.m.

[Message part 2 (text/html, inline)]

Message #11 received at 80001 <at> debbugs.gnu.org (full text, mbox):

From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 80001 <at> debbugs.gnu.org
Subject: Re: bug#80001: [PATCH 1/1] Support `toolkit-theme-set-functions' on
 macOS
Date: Mon, 15 Dec 2025 22:58:38 +0100

[Message part 1 (text/plain, inline)]

Hello Stéphane,

many thanks for your mindful comment.

Stéphane Marks <shipmints <at> gmail.com> writes:

> [...]
> One thing I might change is to use notifications since this is a
> system-wide effect.  For an example, look for
> NSApplicationDidChangeScreenParametersNotification in nsterm.m.

This notification is under a "#ifdef NS_IMPL_GNUSTEP" in nsterm.m. I
checked the docs to see whether it could be used for this purpose. It os
mentioned in the GNUStep GUI library API docs [1]:

---------------------------- Begin Quote -----------------------------
NSApplicationDidChangeScreenParametersNotification

NSString* NSApplicationDidChangeScreenParametersNotification;
Availability: OpenStep

Description forthcoming.
----------------------------- End Quote ------------------------------

Hm, a bit terse, isn't it?

The OpenStep docs [2] don't seem to mention it at all?

Apple's documentation for the notification [3] describes it as "Posted
when the configuration of the displays attached to the computer is
changed." And goes on to further explain: "The configuration change can
be made either programmatically or when the user changes settings in the
Displays control panel." Building an Emacs with this notification
enabled on macOS confirms this description; the notification is posted
when a screen is added to, or removed from the system, or when the size
or resolution of a screen changes. It is not posted when the appearance
toggles between light and dark.

I looked through the GNUStep, and macOS docs for another notification
that indicates a light/dark appearance change, but could not seem to
find one. Have I missed it?

The method I am using in my patch (callback on EmacsView) is one of
Apple's officially suggested ways of reacting to appearance changes as
per their docs [4].

Inspired by your comment, I tried the other method described in [4],
which is using a key-value-observer on the effectiveAppearance property
of the EmacsApp. The code is slightly wordier than the view callback,
but not much.

Both approaches cause the functions on the Lisp hook to be called
exactly once per appearance change.

For illustration of what the KVO method implementation looks like, I am
attaching a new patch, too.


Many thanks and looking forward to your thoughts,

  --alexander

[1] https://www.gnustep.org/resources/documentation/Developer/Gui/Reference/TypesAndConstants.html#variable$NSApplicationDidChangeScreenParametersNotification
[2] https://www.gnustep.org/resources/OpenStepSpec/OpenStepSpec.html
[3] https://developer.apple.com/documentation/appkit/nsapplication/didchangescreenparametersnotification
[4] https://developer.apple.com/documentation/uikit/supporting-dark-mode-in-your-interface?language=objc#Update-custom-views-using-specific-methods

[master-7821fb5-KVO Method Implementation.patch (text/x-patch, inline)]

From 7821fb59569c1cc373b5c7c8143479ac245cda91 Mon Sep 17 00:00:00 2001
From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
Date: Mon, 15 Dec 2025 22:57:24 +0100
Subject: [PATCH] KVO Method Implementation

---
 src/nsterm.m | 67 +++++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 53 insertions(+), 14 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index 5f47dbffc51..35952cd5ffc 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -6354,7 +6354,16 @@ - (void)applicationDidFinishLaunching: (NSNotification *)notification
 	       allocInitFromFile:
 		 build_string("icons/hicolor/128x128/apps/emacs.png")]];
   }
-#endif
+#if MAC_OS_X_VERSION_MIN_REQUIRED >= 101400
+  /* Add a key-value-observer for the app's effective appearance
+     property.  This is used to generate a TOOLKIT_THEME_CHANGED_EVENT
+     when the UI appearance changes. */
+  [self addObserver:self
+	 forKeyPath:@"effectiveAppearance"
+	    options:NSKeyValueObservingOptionNew
+	    context:nil];
+#endif /* MAC_OS_X_VERSION_MIN_REQUIRED >= 101400 */
+#endif /* NS_IMPL_COCOA */
 
   ns_send_appdefined (-2);
 }
@@ -6538,6 +6547,36 @@ - (void)applicationDidResignActive: (NSNotification *)notification
   ns_send_appdefined (-1);
 }
 
+#if (defined NS_IMPL_COCOA) && (MAC_OS_X_VERSION_MIN_REQUIRED >= 101400)
+- (void)observeValueForKeyPath:(NSString *)keyPath
+                      ofObject:(id)object
+                        change:(NSDictionary *)change
+                       context:(void *)context
+{
+  if ([keyPath isEqualToString:@"effectiveAppearance"])
+    {
+      if (! ([[change valueForKey:@"notificationIsPrior"] intValue] == 1))
+	{
+	  NSAppearanceName appearance = [[self effectiveAppearance] name];
+	  struct input_event inev;
+
+	  EVENT_INIT (inev);
+	  inev.kind = TOOLKIT_THEME_CHANGED_EVENT;
+	  inev.arg = [appearance localizedStandardContainsString:@"Dark"] ? Qdark : Qlight;
+	  kbd_buffer_store_event (&inev);
+	  ns_send_appdefined (-1);
+	}
+    }
+  else
+    {
+      /* Any unrecognized key path must belong to super */
+      [super observeValueForKeyPath:keyPath
+			   ofObject:object
+			     change:change
+			    context:context];
+    }
+}
+#endif /* (defined NS_IMPL_COCOA) && (MAC_OS_X_VERSION_MIN_REQUIRED >= 101400) */
 
 
 /* ==========================================================================
@@ -8141,19 +8180,19 @@ - (void)viewDidEndLiveResize
 }
 #endif /* NS_IMPL_COCOA */
 
-#if (defined NS_IMPL_COCOA) && (MAC_OS_X_VERSION_MIN_REQUIRED >= 101400)
-- (void)viewDidChangeEffectiveAppearance
-{
-  NSAppearanceName appearance = [[NSApp effectiveAppearance] name];
-  struct input_event inev;
-
-  EVENT_INIT (inev);
-  inev.kind = TOOLKIT_THEME_CHANGED_EVENT;
-  inev.arg = [appearance localizedStandardContainsString:@"Dark"] ? Qdark : Qlight;
-  kbd_buffer_store_event (&inev);
-  ns_send_appdefined (-1);
-}
-#endif /* (defined NS_IMPL_COCOA) && (MAC_OS_X_VERSION_MIN_REQUIRED >= 101400) */
+// #if (defined NS_IMPL_COCOA) && (MAC_OS_X_VERSION_MIN_REQUIRED >= 101400)
+// - (void)viewDidChangeEffectiveAppearance
+// {
+//   NSAppearanceName appearance = [[NSApp effectiveAppearance] name];
+//   struct input_event inev;
+//
+//   EVENT_INIT (inev);
+//   inev.kind = TOOLKIT_THEME_CHANGED_EVENT;
+//   inev.arg = [appearance localizedStandardContainsString:@"Dark"] ? Qdark : Qlight;
+//   kbd_buffer_store_event (&inev);
+//   ns_send_appdefined (-1);
+// }
+// #endif /* (defined NS_IMPL_COCOA) && (MAC_OS_X_VERSION_MIN_REQUIRED >= 101400) */
 
 - (void)resizeWithOldSuperviewSize: (NSSize)oldSize
 {
-- 
2.50.1

Message #14 received at 80001 <at> debbugs.gnu.org (full text, mbox):

From: Stéphane Marks <shipmints <at> gmail.com>
To: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
Cc: 80001 <at> debbugs.gnu.org
Subject: Re: bug#80001: [PATCH 1/1] Support `toolkit-theme-set-functions' on
 macOS
Date: Mon, 15 Dec 2025 17:24:22 -0500

[Message part 1 (text/plain, inline)]

On Mon, Dec 15, 2025 at 4:58 PM Alexander Adolf <
alexander.adolf <at> condition-alpha.com> wrote:

> Hello Stéphane,
>
> many thanks for your mindful comment.
>
> Stéphane Marks <shipmints <at> gmail.com> writes:
>
> > [...]
> > One thing I might change is to use notifications since this is a
> > system-wide effect.  For an example, look for
> > NSApplicationDidChangeScreenParametersNotification in nsterm.m.
>
> This notification is under a "#ifdef NS_IMPL_GNUSTEP" in nsterm.m. I
> checked the docs to see whether it could be used for this purpose. It os
> mentioned in the GNUStep GUI library API docs [1]:
>
> ---------------------------- Begin Quote -----------------------------
> NSApplicationDidChangeScreenParametersNotification
>
> NSString* NSApplicationDidChangeScreenParametersNotification;
> Availability: OpenStep
>
> Description forthcoming.
> ----------------------------- End Quote ------------------------------
>
> Hm, a bit terse, isn't it?
>
> The OpenStep docs [2] don't seem to mention it at all?
>
> Apple's documentation for the notification [3] describes it as "Posted
> when the configuration of the displays attached to the computer is
> changed." And goes on to further explain: "The configuration change can
> be made either programmatically or when the user changes settings in the
> Displays control panel." Building an Emacs with this notification
> enabled on macOS confirms this description; the notification is posted
> when a screen is added to, or removed from the system, or when the size
> or resolution of a screen changes. It is not posted when the appearance
> toggles between light and dark.
>
> I looked through the GNUStep, and macOS docs for another notification
> that indicates a light/dark appearance change, but could not seem to
> find one. Have I missed it?
>
> The method I am using in my patch (callback on EmacsView) is one of
> Apple's officially suggested ways of reacting to appearance changes as
> per their docs [4].
>
> Inspired by your comment, I tried the other method described in [4],
> which is using a key-value-observer on the effectiveAppearance property
> of the EmacsApp. The code is slightly wordier than the view callback,
> but not much.
>
> Both approaches cause the functions on the Lisp hook to be called
> exactly once per appearance change.
>
> For illustration of what the KVO method implementation looks like, I am
> attaching a new patch, too.
>
>
> Many thanks and looking forward to your thoughts,
>
>   --alexander
>
> [1]
> https://www.gnustep.org/resources/documentation/Developer/Gui/Reference/TypesAndConstants.html#variable$NSApplicationDidChangeScreenParametersNotification
> [2] https://www.gnustep.org/resources/OpenStepSpec/OpenStepSpec.html
> [3]
> https://developer.apple.com/documentation/appkit/nsapplication/didchangescreenparametersnotification
> [4]
> https://developer.apple.com/documentation/uikit/supporting-dark-mode-in-your-interface?language=objc#Update-custom-views-using-specific-methods
>

I think you'd add an observer to the effectiveAppearance property via the
notification center.  See
https://developer.apple.com/documentation/objectivec/nsobject-swift.class/addobserver(_:forkeypath:options:context:)?language=objc
and
also in nsterm.m look for addObserver which I think you already found.
It's the same concept but the key would be something
like forKeyPath:NSStringFromSelector(@selector(effectiveAppearance)).

[Message part 2 (text/html, inline)]

Message #17 received at 80001 <at> debbugs.gnu.org (full text, mbox):

From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 80001 <at> debbugs.gnu.org
Subject: Re: bug#80001: [PATCH 1/1] Support `toolkit-theme-set-functions' on
 macOS
Date: Tue, 16 Dec 2025 22:34:18 +0100

Stéphane Marks <shipmints <at> gmail.com> writes:

> [...]
> I think you'd add an observer to the effectiveAppearance property via the
> notification center.  See
> https://developer.apple.com/documentation/objectivec/nsobject-swift.class/addobserver(_:forkeypath:options:context:)?language=objc
> and
> also in nsterm.m look for addObserver which I think you already found.
> It's the same concept but the key would be something
> like forKeyPath:NSStringFromSelector(@selector(effectiveAppearance)).

I think we might be confused by similar sounding things here?

The first things is the NSNotificationCenter methods

    addObserverForName:object:queue:usingBlock:
    addObserver:selector:name:object:

These cause the observer to be sent messages when NSNotificationCenter
receives a specific notification. There is no notification for
light/dark appearance change, however. Hence, for the purposes of
reacting to light/dark appearance changes, these NSNotificationCenter
methods will not be able to help us.


The second thing is the NSObject method

    observeValueForKeyPath:ofObject:change:context:

which could seem usable to observe the effectiveAppearance property of
the NSApp singleton at first glance. This appears to be what you have in
mind? And the documentation I referenced in my previous message does
suggest this method.

However, I just realised that said documentation is for UIKIt, not
AppKit (as is used by Emacs's NS port). Some experiments I did today
show indeed that the KVO method does not work reliably when not using
UIKit.

Revisiting the AppKit documentation confirmed to me that the one and
only official AppKit way for reacting to light/dark appearance
changes, is the NSView method viewDidChangeEffectiveAppearance.

Thus, my conclusion is that my initial patch is the only approach which
works reliably for me.


Many thanks and looking forward to your thoughts,

  --alexander

Message #20 received at 80001 <at> debbugs.gnu.org (full text, mbox):

From: Stéphane Marks <shipmints <at> gmail.com>
To: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
Cc: 80001 <at> debbugs.gnu.org
Subject: Re: bug#80001: [PATCH 1/1] Support `toolkit-theme-set-functions' on
 macOS
Date: Tue, 16 Dec 2025 16:42:01 -0500

[Message part 1 (text/plain, inline)]

On Tue, Dec 16, 2025 at 4:34 PM Alexander Adolf <
alexander.adolf <at> condition-alpha.com> wrote:

> Stéphane Marks <shipmints <at> gmail.com> writes:
>
> > [...]
> > I think you'd add an observer to the effectiveAppearance property via the
> > notification center.  See
> >
> https://developer.apple.com/documentation/objectivec/nsobject-swift.class/addobserver(_:forkeypath:options:context:)?language=objc
> > and
> > also in nsterm.m look for addObserver which I think you already found.
> > It's the same concept but the key would be something
> > like forKeyPath:NSStringFromSelector(@selector(effectiveAppearance)).
>
> I think we might be confused by similar sounding things here?
>
> The first things is the NSNotificationCenter methods
>
>     addObserverForName:object:queue:usingBlock:
>     addObserver:selector:name:object:
>
> These cause the observer to be sent messages when NSNotificationCenter
> receives a specific notification. There is no notification for
> light/dark appearance change, however. Hence, for the purposes of
> reacting to light/dark appearance changes, these NSNotificationCenter
> methods will not be able to help us.
>
>
> The second thing is the NSObject method
>
>     observeValueForKeyPath:ofObject:change:context:
>
> which could seem usable to observe the effectiveAppearance property of
> the NSApp singleton at first glance. This appears to be what you have in
> mind? And the documentation I referenced in my previous message does
> suggest this method.
>
> However, I just realised that said documentation is for UIKIt, not
> AppKit (as is used by Emacs's NS port). Some experiments I did today
> show indeed that the KVO method does not work reliably when not using
> UIKit.
>
> Revisiting the AppKit documentation confirmed to me that the one and
> only official AppKit way for reacting to light/dark appearance
> changes, is the NSView method viewDidChangeEffectiveAppearance.
>
> Thus, my conclusion is that my initial patch is the only approach which
> works reliably for me.
>

Did you try it?  I see observers for effectiveAppearance in the wild.

Here's an example from Chromium
https://github.com/chromium/chromium/blob/8a16b70db3565e50d784baf762251bf3e8282e00/ui/native_theme/os_settings_provider_mac.mm#L24
You
can google for more.

[Message part 2 (text/html, inline)]

Message #23 received at 80001 <at> debbugs.gnu.org (full text, mbox):

From: Stéphane Marks <shipmints <at> gmail.com>
To: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
Cc: 80001 <at> debbugs.gnu.org
Subject: Re: bug#80001: [PATCH 1/1] Support `toolkit-theme-set-functions' on
 macOS
Date: Tue, 16 Dec 2025 18:59:35 -0500

[Message part 1 (text/plain, inline)]

On Tue, Dec 16, 2025 at 4:42 PM Stéphane Marks <shipmints <at> gmail.com> wrote:

> On Tue, Dec 16, 2025 at 4:34 PM Alexander Adolf <
> alexander.adolf <at> condition-alpha.com> wrote:
>
>> Stéphane Marks <shipmints <at> gmail.com> writes:
>>
>> > [...]
>> > I think you'd add an observer to the effectiveAppearance property via
>> the
>> > notification center.  See
>> >
>> https://developer.apple.com/documentation/objectivec/nsobject-swift.class/addobserver(_:forkeypath:options:context:)?language=objc
>> > and
>> > also in nsterm.m look for addObserver which I think you already found.
>> > It's the same concept but the key would be something
>> > like forKeyPath:NSStringFromSelector(@selector(effectiveAppearance)).
>>
>> I think we might be confused by similar sounding things here?
>>
>> The first things is the NSNotificationCenter methods
>>
>>     addObserverForName:object:queue:usingBlock:
>>     addObserver:selector:name:object:
>>
>> These cause the observer to be sent messages when NSNotificationCenter
>> receives a specific notification. There is no notification for
>> light/dark appearance change, however. Hence, for the purposes of
>> reacting to light/dark appearance changes, these NSNotificationCenter
>> methods will not be able to help us.
>>
>>
>> The second thing is the NSObject method
>>
>>     observeValueForKeyPath:ofObject:change:context:
>>
>> which could seem usable to observe the effectiveAppearance property of
>> the NSApp singleton at first glance. This appears to be what you have in
>> mind? And the documentation I referenced in my previous message does
>> suggest this method.
>>
>> However, I just realised that said documentation is for UIKIt, not
>> AppKit (as is used by Emacs's NS port). Some experiments I did today
>> show indeed that the KVO method does not work reliably when not using
>> UIKit.
>>
>> Revisiting the AppKit documentation confirmed to me that the one and
>> only official AppKit way for reacting to light/dark appearance
>> changes, is the NSView method viewDidChangeEffectiveAppearance.
>>
>> Thus, my conclusion is that my initial patch is the only approach which
>> works reliably for me.
>>
>
> Did you try it?  I see observers for effectiveAppearance in the wild.
>
> Here's an example from Chromium
> https://github.com/chromium/chromium/blob/8a16b70db3565e50d784baf762251bf3e8282e00/ui/native_theme/os_settings_provider_mac.mm#L24 You
> can google for more.
>

And, not to taint your intellectual property, but here's a long-standing NS
appearance patch that appears to observe changes in the effectiveAppearance
property
https://github.com/d12frosted/homebrew-emacs-plus/blob/master/patches/emacs-31/system-appearance.patch

[Message part 2 (text/html, inline)]

Message #26 received at 80001 <at> debbugs.gnu.org (full text, mbox):

From: Stéphane Marks <shipmints <at> gmail.com>
To: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
Cc: 80001 <at> debbugs.gnu.org
Subject: Re: bug#80001: [PATCH 1/1] Support `toolkit-theme-set-functions' on
 macOS
Date: Tue, 16 Dec 2025 19:04:47 -0500

[Message part 1 (text/plain, inline)]

On Tue, Dec 16, 2025 at 6:59 PM Stéphane Marks <shipmints <at> gmail.com> wrote:

> On Tue, Dec 16, 2025 at 4:42 PM Stéphane Marks <shipmints <at> gmail.com>
> wrote:
>
>> On Tue, Dec 16, 2025 at 4:34 PM Alexander Adolf <
>> alexander.adolf <at> condition-alpha.com> wrote:
>>
>>> Stéphane Marks <shipmints <at> gmail.com> writes:
>>>
>>> > [...]
>>> > I think you'd add an observer to the effectiveAppearance property via
>>> the
>>> > notification center.  See
>>> >
>>> https://developer.apple.com/documentation/objectivec/nsobject-swift.class/addobserver(_:forkeypath:options:context:)?language=objc
>>> > and
>>> > also in nsterm.m look for addObserver which I think you already found.
>>> > It's the same concept but the key would be something
>>> > like forKeyPath:NSStringFromSelector(@selector(effectiveAppearance)).
>>>
>>> I think we might be confused by similar sounding things here?
>>>
>>> The first things is the NSNotificationCenter methods
>>>
>>>     addObserverForName:object:queue:usingBlock:
>>>     addObserver:selector:name:object:
>>>
>>> These cause the observer to be sent messages when NSNotificationCenter
>>> receives a specific notification. There is no notification for
>>> light/dark appearance change, however. Hence, for the purposes of
>>> reacting to light/dark appearance changes, these NSNotificationCenter
>>> methods will not be able to help us.
>>>
>>>
>>> The second thing is the NSObject method
>>>
>>>     observeValueForKeyPath:ofObject:change:context:
>>>
>>> which could seem usable to observe the effectiveAppearance property of
>>> the NSApp singleton at first glance. This appears to be what you have in
>>> mind? And the documentation I referenced in my previous message does
>>> suggest this method.
>>>
>>> However, I just realised that said documentation is for UIKIt, not
>>> AppKit (as is used by Emacs's NS port). Some experiments I did today
>>> show indeed that the KVO method does not work reliably when not using
>>> UIKit.
>>>
>>> Revisiting the AppKit documentation confirmed to me that the one and
>>> only official AppKit way for reacting to light/dark appearance
>>> changes, is the NSView method viewDidChangeEffectiveAppearance.
>>>
>>> Thus, my conclusion is that my initial patch is the only approach which
>>> works reliably for me.
>>>
>>
>> Did you try it?  I see observers for effectiveAppearance in the wild.
>>
>> Here's an example from Chromium
>> https://github.com/chromium/chromium/blob/8a16b70db3565e50d784baf762251bf3e8282e00/ui/native_theme/os_settings_provider_mac.mm#L24 You
>> can google for more.
>>
>
> And, not to taint your intellectual property, but here's a long-standing
> NS appearance patch that appears to observe changes in the
> effectiveAppearance property
> https://github.com/d12frosted/homebrew-emacs-plus/blob/master/patches/emacs-31/system-appearance.patch
>

I just took a look at emacs-mac, the non-NS "Mitsuharu" Emacs build and it,
too, uses observers, though its implementation is even more clever,
abstracting the interface to key-value observers to Elisp so stanzas like
this work

  (define-key mac-apple-event-map [application-kvo effectiveAppearance]
    'mac-handle-application-effective-appearance-change)

Hope that all helps.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.