GNU bug report logs - #51404
Support system dark mode on Windows 10

Previous Next

Full log

View this message in rfc822 format

From: Vince Salvino <salvino <at> coderedcorp.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "51404 <at> debbugs.gnu.org" <51404 <at> debbugs.gnu.org>
Subject: bug#51404: Support system dark mode on Windows 10
Date: Tue, 26 Oct 2021 18:20:35 +0000

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

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 <at> gnu.org> 
Sent: Tuesday, October 26, 2021 1:06 PM
To: Vince Salvino <salvino <at> coderedcorp.com>
Cc: 51404 <at> debbugs.gnu.org
Subject: Re: bug#51404: Support system dark mode on Windows 10

> From: Vince Salvino <salvino <at> coderedcorp.com>
> CC: "51404 <at> debbugs.gnu.org" <51404 <at> 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 (application/octet-stream, attachment)]

Previous Next

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