bug#47291: bug#51404: Support system dark mode on Windows 10

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: salvino@coderedcorp.com,  51404@debbugs.gnu.org,  47291@debbugs.gnu.org
> Date: Thu, 11 Nov 2021 13:15:03 +0100
> 
> Eli Zaretskii <eliz@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.