bug#51404: Support system dark mode on Windows 10

[Eli Zaretskii]

> From: Vince Salvino <salvino@coderedcorp.com>
> CC: "51404@debbugs.gnu.org" <51404@debbugs.gnu.org>
> Date: Tue, 26 Oct 2021 16:49:34 +0000
> 
> > > +#define DARK_MODE_APP_NAME L"DarkMode_Explorer"
> 
> > Can we make this exposed to Lisp, rather than hard-coded?  Hard-coding a 
> > specific application for a theme sounds un-Emacsy.  People could want to 
> > experiment with other apps.
> 
> Given that this is not so much a preference, as an undocumented magic string 
> in Win32, I think anyone who wants to play with this is going to require 
> knowledge of C and gdb to experiment, to risk causing erratic and unknown 
> behavior. So I would be inclined to keep it in C.

These "undocumented" strings are all over the Internet, so...

Here are some examples that people may wish trying:

  https://stackoverflow.com/questions/19712368/c-winapi-old-styled-window
  
https://developercommunity.visualstudio.com/t/tree-controls-not-displayed-correctly-in-windows-1/423037

And this is just from a couple of minutes of searching the Internet.

> > +/* Applies the Windows system theme (light or dark) to a window 
> > +handle. */ static void w32_applytheme(HWND hwnd) {
> > +  if (w32_darkmode) {
> > +    /* Set window theme to that of a built-in Windows app (Explorer)
> > +       because it has dark scroll bars and other UI elements. */
> 
> > Likewise here: it should be able to control this behavior by a user option. 
> >  We cannot assume that every Emacs user will automatically want to follow 
> > the system theme.
> 
> I agree this would be a "nice to have", but the current functionality is 
> in-line with behavior on other systems (GTK, macOS, etc. i.e. the application 
> has no say in window decorations which are controlled by the window manager). 
> If we did add an elisp setting it should default to the registry value at 
> runtime. I also have no idea how to create an elisp setting and read it in C. 
> Examples or contributions to this patch would be helpful.

The GTK behavior is a bad example, so I'd rather not follow it.
Doesn't the patch in its current form unconditionally change the
appearance of Emacs in some cases?  I think it does, and that means we
will have complaints about unexpected change in behavior.  You can
also bet on someone disliking the result.  So I think this has to be
customizable; let me know if you need help in doing that.