GNU bug report logs - #47291
[PATCH] Auto-detect ns-appearance of frames and call a hook when it changes

Previous Next

To reply to this bug, email your comments to 47291 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: Daphne Preston-Kendal <dpk <at> nonceword.org>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Auto-detect ns-appearance of frames and call a hook when it
 changes
Date: Sun, 21 Mar 2021 11:48:10 +0100

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

This is a slightly cleaned-up version of the patch I initially posted for
commentary on emacs-devel.
<https://lists.gnu.org/archive/html/emacs-devel/2021-03/msg00482.html>

The patch makes two closely related changes: when a new frame is
created, the ns-appearance parameter (which was already in Emacs) is
bound to 'light or 'dark depending on the system theme. (Previously,
it could be set explicitly and Emacs would respect that change on a
per-frame basis, but if it wasn't explicitly set it was unbound.)
Secondly, it registers an event handler for changes to the system-wide
theme, and when the system theme changes, it changes the ns-appearance
parameter of all frames to match the new system theme, and runs a new
hook, ns-dark-mode-changed-hook so that users can e.g. set a new Emacs
theme to match the new system theme or whatever.

The patch is against Emacs HEAD as of time of writing. (3cbf92323c)

As mentioned on emacs-devel, this is my first Emacs patch and my first
time programming Objective-C in a long while, so I’d definitely
appreciate feedback!


Daphne Preston-Kendal

[0001-Auto-detect-ns-appearance-of-frames-and-call-a-hook-.patch (application/octet-stream, attachment)]

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

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

From: Matt Armstrong <matt <at> rfc20.org>
To: Daphne Preston-Kendal <dpk <at> nonceword.org>, 47291 <at> debbugs.gnu.org
Subject: Re: bug#47291: [PATCH] Auto-detect ns-appearance of frames and call
 a hook when it changes
Date: Tue, 23 Mar 2021 11:05:59 -0700

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

> This is a slightly cleaned-up version of the patch I initially posted for
> commentary on emacs-devel.
> <https://lists.gnu.org/archive/html/emacs-devel/2021-03/msg00482.html>
>
> The patch makes two closely related changes: when a new frame is
> created, the ns-appearance parameter (which was already in Emacs) is
> bound to 'light or 'dark depending on the system theme. (Previously,
> it could be set explicitly and Emacs would respect that change on a
> per-frame basis, but if it wasn't explicitly set it was unbound.)

I think GTK already has similar functionality.  When I change the GTK
theme Emacs' frame decorations change accordingly.  So, to me this part
of the patch seems fine from the policy perspective that Lars raised on
emacs-devel.


> Secondly, it registers an event handler for changes to the system-wide
> theme, and when the system theme changes, it changes the ns-appearance
> parameter of all frames to match the new system theme, and runs a new
> hook, ns-dark-mode-changed-hook so that users can e.g. set a new Emacs
> theme to match the new system theme or whatever.

I suggested an alternative approach on emacs-devel -- use the
dynamic-setting.el mechanism which is used for GTK but expressed in a
general way.

Since Emacs already has that mechanism for GTK, I think this approach
would satisfy the policy issue Lars raised as well.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Matt Armstrong <matt <at> rfc20.org>
Cc: Alan Third <alan <at> idiocy.org>, 47291 <at> debbugs.gnu.org,
 Daphne Preston-Kendal <dpk <at> nonceword.org>
Subject: Re: bug#47291: [PATCH] Auto-detect ns-appearance of frames and call
 a hook when it changes
Date: Tue, 18 May 2021 16:43:33 +0200

Matt Armstrong <matt <at> rfc20.org> writes:

> I suggested an alternative approach on emacs-devel -- use the
> dynamic-setting.el mechanism which is used for GTK but expressed in a
> general way.
>
> Since Emacs already has that mechanism for GTK, I think this approach
> would satisfy the policy issue Lars raised as well.

Yes, I think that might make sense...  but I've added Alan to the CCs,
since this affects Macos things.  Perhaps he has some comments on these
alternative approaches.

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

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

From: Alan Third <alan <at> idiocy.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Matt Armstrong <matt <at> rfc20.org>, 47291 <at> debbugs.gnu.org,
 Daphne Preston-Kendal <dpk <at> nonceword.org>
Subject: Re: bug#47291: [PATCH] Auto-detect ns-appearance of frames and call
 a hook when it changes
Date: Tue, 18 May 2021 18:44:42 +0100

On Tue, May 18, 2021 at 04:43:33PM +0200, Lars Ingebrigtsen wrote:
> Matt Armstrong <matt <at> rfc20.org> writes:
> 
> > I suggested an alternative approach on emacs-devel -- use the
> > dynamic-setting.el mechanism which is used for GTK but expressed in a
> > general way.
> >
> > Since Emacs already has that mechanism for GTK, I think this approach
> > would satisfy the policy issue Lars raised as well.
> 
> Yes, I think that might make sense...  but I've added Alan to the CCs,
> since this affects Macos things.  Perhaps he has some comments on these
> alternative approaches.

I don't really have much of an opinion. I feel tying in with
pre-existing functionality is probably the way to go but I don't know
anything about it.

I think the first part of Daphne's change can go straight in if it's
in a separate patch.

-- 
Alan Third

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

From: Daphne Preston-Kendal <dpk <at> nonceword.org>
To: Matt Armstrong <matt <at> rfc20.org>
Cc: 47291 <at> debbugs.gnu.org
Subject: Re: bug#47291: [PATCH] Auto-detect ns-appearance of frames and call a
 hook when it changes
Date: Tue, 18 May 2021 20:03:04 +0200

On 23 Mar 2021, at 19:05, Matt Armstrong <matt <at> rfc20.org> wrote:

> I suggested an alternative approach on emacs-devel -- use the
> dynamic-setting.el mechanism which is used for GTK but expressed in a
> general way.

I took a look at dynamic-setting.el but couldn’t quite see how what
this patch does would fit in with it/how it would enable the same
functionality as this patch provides. It doesn’t seem to be
documented? (Though in fairness, either is my patch at the moment!)

The goal of this patch is to allow Emacs to automatically select
different themes depending on the system-wide setting, and
automatically change which theme is in use when the system-wide
setting changes. There may be multiple themes involved in the change —
for instance, I would want the light smart-mode-line theme plus light
buffer theme enabled when the system is in light mode, but both should
be deactivated and changed to the dark smart-mode-line and buffer
themes when the system changes to dark mode.

Is it possible to do that within the framework of what dynamic-setting
provides? Sorry if this is obvious, I’m just not familiar with this
bit of Emacs.


Daphne

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

From: Daphne Preston-Kendal <dpk <at> nonceword.org>
To: 47291 <at> debbugs.gnu.org
Subject: Re: bug#47291: [PATCH] Auto-detect ns-appearance of frames and call a
 hook when it changes
Date: Fri, 8 Oct 2021 10:24:16 +0200

On 18 May 2021, at 20:03, Daphne Preston-Kendal <dpk <at> nonceword.org> wrote:

> Is it possible to do that within the framework of what dynamic-setting
> provides? Sorry if this is obvious, I’m just not familiar with this
> bit of Emacs.

Since there have been no answers since May, I’d like to suggest/
request that my patch be merged in more or less as it is. If there is
an OS-portable mechanism for detecting light/dark switches somewhere
in a Lisp library, like dynamic-setting.el, then the patch I provide
here can still work as the underlying C implementation, and we can
bridge them together at the Lisp level later. An analogy for this
approach would be how the Lisp-level interprogram-{cut,paste}-function
settings bridge to underlying ns-get-selection and ns-own-selection
functions on Mac OS, but to other things on free OSes.

I’d really like to see this in Emacs 28 if possible!


Daphne

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Vince Salvino <salvino <at> coderedcorp.com>, 51404 <at> debbugs.gnu.org,
 47291 <at> debbugs.gnu.org
Subject: Re: bug#51404: Support system dark mode on Windows 10
Date: Thu, 11 Nov 2021 06:36:09 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> I'm not sure I understand why 'light' necessarily means the old
> behavior: we didn't set any theme before this change, we just used the
> Windows default.  So maybe there should be 4 values:
>
>   nil: never follow the system theme (use Windows default)
>   t: always follow the system theme
>   light: force light theme (currently the same as nil)
>   dark: force dark theme.

For a similar bug report, see bug#47291.  And we really should support
this on GNU/Linux, too, so having three different methods to support
this seems sub-optimal.

dynamic-setting.el seems like the most likely place to centralise all
this, I think?  I've had a look at what happens when you change the
theme in Gnome, and dynamic-setting-handle-config-changed-event gets
called with an

 (config-changed-event theme-name ":1")

event.  (But not what the event name is -- anybody know how to get at
that?)

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: salvino <at> coderedcorp.com, 51404 <at> debbugs.gnu.org, 47291 <at> debbugs.gnu.org
Subject: Re: bug#51404: Support system dark mode on Windows 10
Date: Thu, 11 Nov 2021 09:51:16 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Vince Salvino <salvino <at> coderedcorp.com>,  51404 <at> debbugs.gnu.org,
>  47291 <at> debbugs.gnu.org
> Date: Thu, 11 Nov 2021 06:36:09 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I'm not sure I understand why 'light' necessarily means the old
> > behavior: we didn't set any theme before this change, we just used the
> > Windows default.  So maybe there should be 4 values:
> >
> >   nil: never follow the system theme (use Windows default)
> >   t: always follow the system theme
> >   light: force light theme (currently the same as nil)
> >   dark: force dark theme.
> 
> For a similar bug report, see bug#47291.  And we really should support
> this on GNU/Linux, too, so having three different methods to support
> this seems sub-optimal.

I'm not sure unification is possible here, because the functionality
is quite different, AFAICT.  At least for the functionality in this
bug report, we cannot apply the system theme to an existing frame, we
can only apply it at frame creation time.  So having a handler for
such changes will be able to affect only the frames created after the
change.  Or at least that is my understanding; the code definitely
applies the dark/light theme as part of creating a frame.

Also, having a dynamic thing that tracks changes in these settings
would on Windows mean listening and processing a special window-system
message, which seems to be WM_THEMECHANGED or maybe WM_SETTINGCHANGE.
But that's not what the code installed in this bug report does.

So the functionality seems similar, but the details differ.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: salvino <at> coderedcorp.com, 51404 <at> debbugs.gnu.org, 47291 <at> debbugs.gnu.org
Subject: Re: bug#51404: Support system dark mode on Windows 10
Date: Thu, 11 Nov 2021 13:15:03 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> I'm not sure unification is possible here, because the functionality
> is quite different, AFAICT.  At least for the functionality in this
> bug report, we cannot apply the system theme to an existing frame, we
> can only apply it at frame creation time.  So having a handler for
> such changes will be able to affect only the frames created after the
> change.  Or at least that is my understanding; the code definitely
> applies the dark/light theme as part of creating a frame.

Gtk Emacs doesn't respond to dark mode either -- so we have the
opportunity to decide how to handle these things across the board.
Perhaps in Gtk Emacs, dynamic-setting-handle-config-changed-event should
also just set something that will make the next frame creation use
different colours?

> Also, having a dynamic thing that tracks changes in these settings
> would on Windows mean listening and processing a special window-system
> message, which seems to be WM_THEMECHANGED or maybe WM_SETTINGCHANGE.
> But that's not what the code installed in this bug report does.
>
> So the functionality seems similar, but the details differ.

But perhaps Windows should be listening to those events, too?

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: salvino <at> coderedcorp.com, 51404 <at> debbugs.gnu.org, 47291 <at> debbugs.gnu.org
Subject: Re: bug#51404: Support system dark mode on Windows 10
Date: Thu, 11 Nov 2021 17:08:04 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: salvino <at> coderedcorp.com,  51404 <at> debbugs.gnu.org,  47291 <at> debbugs.gnu.org
> Date: Thu, 11 Nov 2021 13:15:03 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I'm not sure unification is possible here, because the functionality
> > is quite different, AFAICT.  At least for the functionality in this
> > bug report, we cannot apply the system theme to an existing frame, we
> > can only apply it at frame creation time.  So having a handler for
> > such changes will be able to affect only the frames created after the
> > change.  Or at least that is my understanding; the code definitely
> > applies the dark/light theme as part of creating a frame.
> 
> Gtk Emacs doesn't respond to dark mode either -- so we have the
> opportunity to decide how to handle these things across the board.
> Perhaps in Gtk Emacs, dynamic-setting-handle-config-changed-event should
> also just set something that will make the next frame creation use
> different colours?

If that's what people want, sure.  I'd expect them to want Emacs to go
to dark background on all frames.

> > Also, having a dynamic thing that tracks changes in these settings
> > would on Windows mean listening and processing a special window-system
> > message, which seems to be WM_THEMECHANGED or maybe WM_SETTINGCHANGE.
> > But that's not what the code installed in this bug report does.
> >
> > So the functionality seems similar, but the details differ.
> 
> But perhaps Windows should be listening to those events, too?

Maybe.  But some expert (which is not me) will have to explain what to
do when we receive these messages, or submit patches for that.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: salvino <at> coderedcorp.com, 51404 <at> debbugs.gnu.org, 47291 <at> debbugs.gnu.org
Subject: Re: bug#51404: Support system dark mode on Windows 10
Date: Fri, 12 Nov 2021 04:00:18 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> If that's what people want, sure.  I'd expect them to want Emacs to go
> to dark background on all frames.

Possibly -- there should probably be a user option, I guess.

> Maybe.  But some expert (which is not me) will have to explain what to
> do when we receive these messages, or submit patches for that.

On the Linux side, we convert the messages to input events and then
react to that event from special-event-map, which seems like a
reasonable structure.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: salvino <at> coderedcorp.com, 51404 <at> debbugs.gnu.org, 47291 <at> debbugs.gnu.org
Subject: Re: bug#51404: Support system dark mode on Windows 10
Date: Fri, 12 Nov 2021 08:19:22 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: salvino <at> coderedcorp.com,  51404 <at> debbugs.gnu.org,  47291 <at> debbugs.gnu.org
> Date: Fri, 12 Nov 2021 04:00:18 +0100
> 
> > Maybe.  But some expert (which is not me) will have to explain what to
> > do when we receive these messages, or submit patches for that.
> 
> On the Linux side, we convert the messages to input events and then
> react to that event from special-event-map, which seems like a
> reasonable structure.

I mean how to tell what the message wants us to do, i.e. which parts
of the UI to change and in what way.

Previous Next

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