bug#51404: Support system dark mode on Windows 10

[Vince Salvino]

Attached is the patch with some of your comments resolved.

Regarding exposing DARK_MODE_APP_NAME to lisp, I am staunchly against that. If 
users want to potentially segfault their emacs, or make the frame 
invisible/unusable, they are more than welcome to play with the C code.

Regarding toggling dark mode from within lisp, I think that is a decent idea, 
and left a TODO in the relevant place in the code. Help would be appreciated 
here. The current functionality is not "unconditional" per se, it follows the 
user-configurable OS setting (which is light by default, so no visual change 
from previous versions of Emacs). The manual has been updated with a relevant 
note.


Vince Salvino

-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org> 
Sent: Tuesday, October 26, 2021 1:06 PM
To: Vince Salvino <salvino@coderedcorp.com>
Cc: 51404@debbugs.gnu.org
Subject: Re: bug#51404: Support system dark mode on Windows 10

> 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.

0001-Support-system-dark-mode-on-Windows-10-version-2004-.patch
Description: 0001-Support-system-dark-mode-on-Windows-10-version-2004-.patch