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

Previous Next

Full log

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.

Previous Next

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