Dark mode on Windows

Dark mode on Windows

[Vince Salvino]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

Windows 10 has a system-wide "dark mode", which if supported by an app, can tell the app to use dark title bars, scrollbars, etc.

In a fit of rage after staring at the blinding white titlebar on my Emacs frame, I researched the issue and implemented "dark mode" in Emacs for Windows (the rage had been building for years).

Here is a work in progress, which seemingly works quite well, but needs a bit more work. Would anyone be able to help, or possibly help get such a feature merged in?

See README.md in my fork: https://github.com/vsalvino/emacs


Vince Salvino

[-- Attachment #2: Type: text/html, Size: 2550 bytes --]

Re: Dark mode on Windows

[Po Lu]

Vince Salvino <salvino@coderedcorp.com> writes:

> Windows 10 has a system-wide “dark mode”, which if supported by an
> app, can tell the app to use dark title bars, scrollbars, etc.
>
>  
>
> In a fit of rage after staring at the blinding white titlebar on my
> Emacs frame, I researched the issue and implemented “dark mode” in
> Emacs for Windows (the rage had been building for years).
>
>  
>
> Here is a work in progress, which seemingly works quite well, but
> needs a bit more work. Would anyone be able to help, or possibly help
> get such a feature merged in?

Is this feature available on free operating systems?

The X11+GTK port, which runs on free operating systems, needs this
feature.

P.S. this is also a problem with the NS port.  The ability to use a dark
stylesheet for window decorations is only available on macOS, and not
GNUstep.

Re: Dark mode on Windows

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Is this feature available on free operating systems?
>
> The X11+GTK port, which runs on free operating systems, needs this
> feature.
>
> P.S. this is also a problem with the NS port.  The ability to use a dark
> stylesheet for window decorations is only available on macOS, and not
> GNUstep.

Some other comments:

+    # darkmode
+    W32_LIBS="$W32_LIBS -ldwmapi"
+    # darkmode

This will not work on Windows NT prior to NT 6.0, or any version of
Windows 9x.

+ /* darkmode */
+ #include <dwmapi.h>
+ #ifndef DWMWA_USE_IMMERSIVE_DARK_MODE
+ #define DWMWA_USE_IMMERSIVE_DARK_MODE 20
+ #endif
+ /* darkmode */

What is the purpose of this define?  Is `DWMWA_USE_IMMERSIVE_DARK_MODE'
an undocumented feature?

+      /* Enable darkmode */
+      BOOL isDarkMode = TRUE;
+      DwmSetWindowAttribute(hwnd,
+			    DWMWA_USE_IMMERSIVE_DARK_MODE,
+			    &isDarkMode,
+			    sizeof(isDarkMode));

This needs to be controllable by the user, and will similarly not work
on slightly old versions of Windows.

Re: Dark mode on Windows

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Is this feature available on free operating systems?
>>
>> The X11+GTK port, which runs on free operating systems, needs this
>> feature.

KDE and other window managers I use on GNU/Linux set themselves the
window decorations, not the application. Is GTK an exception to that?

>> P.S. this is also a problem with the NS port.  The ability to use a dark
>> stylesheet for window decorations is only available on macOS, and not
>> GNUstep.
>
> Some other comments:
>
> +    # darkmode
> +    W32_LIBS="$W32_LIBS -ldwmapi"
> +    # darkmode
>
> This will not work on Windows NT prior to NT 6.0, or any version of
> Windows 9x.

Supporting ancient OSes is not a requirement for accepting patches that
implement new capabilities.

> + /* darkmode */
> + #include <dwmapi.h>
> + #ifndef DWMWA_USE_IMMERSIVE_DARK_MODE
> + #define DWMWA_USE_IMMERSIVE_DARK_MODE 20
> + #endif
> + /* darkmode */
>
> What is the purpose of this define?  Is `DWMWA_USE_IMMERSIVE_DARK_MODE'
> an undocumented feature?

Yes.

> +      /* Enable darkmode */
> +      BOOL isDarkMode = TRUE;
> +      DwmSetWindowAttribute(hwnd,
> +			    DWMWA_USE_IMMERSIVE_DARK_MODE,
> +			    &isDarkMode,
> +			    sizeof(isDarkMode));
>
> This needs to be controllable by the user, and will similarly not work
> on slightly old versions of Windows.

Of course it doesn't work on "slightly old" versions of Windows, because
them lack the feature, as the OP implicitly informs us when he says
"Windows 10 has..."

Why such discouraging review?

Re: Dark mode on Windows

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> KDE and other window managers I use on GNU/Linux set themselves the
> window decorations, not the application. Is GTK an exception to that?

Yes, GTK+ 3.0 provides the ability to use a different style (such as
Adwatia Dark) for window decorations (and GTK+ widgets in general).

AFAIK that if the window does not have client-side decorations, it is
automatically converted to use them.

> Supporting ancient OSes is not a requirement for accepting patches that
> implement new capabilities.

IIUC, this does not just implement new capabilities, but will prevent
Emacs from working at all on older systems.

> Of course it doesn't work on "slightly old" versions of Windows, because
> them lack the feature, as the OP implicitly informs us when he says
> "Windows 10 has..."

Yes, but the function is not dynamically loaded.  This will cause symbol
resolution failures on older systems.

> Why such discouraging review?

I wasn't trying to discourage the OP, just to help.

Re: Dark mode on Windows

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> KDE and other window managers I use on GNU/Linux set themselves the
>> window decorations, not the application. Is GTK an exception to that?
>
> Yes, GTK+ 3.0 provides the ability to use a different style (such as
> Adwatia Dark) for window decorations (and GTK+ widgets in general).

That's the same I was saying about KDE.

> AFAIK that if the window does not have client-side decorations, it is
> automatically converted to use them.

Emacs has no client-side window decorations, right? More specifically,
it does not sets the background of the title frame.

>> Supporting ancient OSes is not a requirement for accepting patches that
>> implement new capabilities.
>
> IIUC, this does not just implement new capabilities, but will prevent
> Emacs from working at all on older systems.

False. Emacs has lots of features that don't work on old systems. Emacs
runs on those systems with those features disabled.

>> Of course it doesn't work on "slightly old" versions of Windows, because
>> them lack the feature, as the OP implicitly informs us when he says
>> "Windows 10 has..."
>
> Yes, but the function is not dynamically loaded.  This will cause symbol
> resolution failures on older systems.

This can be fixed, Emacs already does that on lots of places, moreso
when it runs on Windows.

>> Why such discouraging review?
>
> I wasn't trying to discourage the OP, just to help.

That was not the tone I perceived from here.

Re: Dark mode on Windows

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

>>> KDE and other window managers I use on GNU/Linux set themselves the
>>> window decorations, not the application. Is GTK an exception to that?
>>
>> Yes, GTK+ 3.0 provides the ability to use a different style (such as
>> Adwatia Dark) for window decorations (and GTK+ widgets in general).
>
> That's the same I was saying about KDE.
>
>> AFAIK that if the window does not have client-side decorations, it is
>> automatically converted to use them.

> Emacs has no client-side window decorations, right? More specifically,
> it does not sets the background of the title frame.

What do you mean by background? If you mean the background of the
window, then I think Emacs sets that on X Windows.  See this part of
x_set_background_color in xfns.c:

      XSetWindowBackground (dpy, FRAME_X_WINDOW (f), bg);

What I was commenting on was that GTK+ provides the ability to change
the style of frame decorations on a per-GtkWindow basis.  See
gtk_window_set_titlebar and friends.

> False. Emacs has lots of features that don't work on old systems. Emacs
> runs on those systems with those features disabled.

But linking with dwmapi.dll _WILL_ prevent Emacs from starting on older
systems.

> This can be fixed, Emacs already does that on lots of places, moreso
> when it runs on Windows.

Which is not done in the changes made by the OP.

> That was not the tone I perceived from here.

Whatever tone you might have perceived, I assure you was a misperception
on your part.  I only made comments based on facts.

RE: Dark mode on Windows

[Vince Salvino]

Answering your questions, Po:

> Is this feature available on free operating systems?

This is not a feature of emacs, rather it is a specific feature of Windows which is being supported (e.g. the window manager "chrome" around GUI emacs). Other operating systems have their own window managers, which actually are user-controllable, and would not require such a kludge in emacs :)

> This will not work on Windows NT prior to NT 6.0, or any version of Windows 9x.

I have outlined ideas for this in the README.md in my fork. It would probably be possible to create a separate build profile, similar to NT vs Cygwin, etc. That is a bit beyond my skills, and I have no way of testing those systems.

> What is the purpose of this define?  Is `DWMWA_USE_IMMERSIVE_DARK_MODE' an undocumented feature?

The value set by that define, and its use in DwmSetWindowAttribute, is undocumented (but heavily used and known among developers). See the inspiration links in my README.md.

> This needs to be controllable by the user, and will similarly not work on slightly old versions of Windows.

I have recently addressed the version compatibility issue. There is also a TODO for the controllable aspect.


Vince Salvino

-----Original Message-----
From: Po Lu <luangruo@yahoo.com> 
Sent: Sunday, October 24, 2021 9:23 PM
To: Vince Salvino <salvino@coderedcorp.com>
Cc: emacs-devel@gnu.org
Subject: Re: Dark mode on Windows

Po Lu <luangruo@yahoo.com> writes:

> Is this feature available on free operating systems?
>
> The X11+GTK port, which runs on free operating systems, needs this 
> feature.
>
> P.S. this is also a problem with the NS port.  The ability to use a 
> dark stylesheet for window decorations is only available on macOS, and 
> not GNUstep.

Some other comments:

+    # darkmode
+    W32_LIBS="$W32_LIBS -ldwmapi"
+    # darkmode

This will not work on Windows NT prior to NT 6.0, or any version of Windows 9x.

+ /* darkmode */
+ #include <dwmapi.h>
+ #ifndef DWMWA_USE_IMMERSIVE_DARK_MODE
+ #define DWMWA_USE_IMMERSIVE_DARK_MODE 20 #endif
+ /* darkmode */

What is the purpose of this define?  Is `DWMWA_USE_IMMERSIVE_DARK_MODE'
an undocumented feature?

+      /* Enable darkmode */
+      BOOL isDarkMode = TRUE;
+      DwmSetWindowAttribute(hwnd,
+			    DWMWA_USE_IMMERSIVE_DARK_MODE,
+			    &isDarkMode,
+			    sizeof(isDarkMode));

This needs to be controllable by the user, and will similarly not work on slightly old versions of Windows.

Re: Dark mode on Windows

[Po Lu]

Vince Salvino <salvino@coderedcorp.com> writes:

> This is not a feature of emacs, rather it is a specific feature of
> Windows which is being supported (e.g. the window manager "chrome"
> around GUI emacs). Other operating systems have their own window
> managers, which actually are user-controllable, and would not require
> such a kludge in emacs :)

But in that case, the decorations can't be controlled on a per-frame
basis.  This behaviour is desirable and could potentially drive people
to use proprietary operating systems.

> I have outlined ideas for this in the README.md in my fork. It would
> probably be possible to create a separate build profile, similar to NT
> vs Cygwin, etc. That is a bit beyond my skills, and I have no way of
> testing those systems.

If you find a solution, I can help test on Windows 9x.  But first, is
there any reason `DwmSetWindowAttribute' can't be dynamically loaded,
like many other functions are on MS-Windows?

RE: Dark mode on Windows

[Vince Salvino]

I originally tried dynamically loading dwmapi.dll, and it cannot be done dynamically. It will simply not load. I spent a lot of time head-scratching in gdb to figure this out. From what I read, it behaves a bit differently than other DLLs and has to be linked. This is also my first foray into Win32 programming, so I have exactly zero experience with any of this stuff, and could be wrong.

Vince Salvino

-----Original Message-----
From: Po Lu <luangruo@yahoo.com> 
Sent: Monday, October 25, 2021 12:28 AM
To: Vince Salvino <salvino@coderedcorp.com>
Cc: emacs-devel@gnu.org
Subject: Re: Dark mode on Windows

Vince Salvino <salvino@coderedcorp.com> writes:

> This is not a feature of emacs, rather it is a specific feature of 
> Windows which is being supported (e.g. the window manager "chrome"
> around GUI emacs). Other operating systems have their own window 
> managers, which actually are user-controllable, and would not require 
> such a kludge in emacs :)

But in that case, the decorations can't be controlled on a per-frame basis.  This behaviour is desirable and could potentially drive people to use proprietary operating systems.

> I have outlined ideas for this in the README.md in my fork. It would 
> probably be possible to create a separate build profile, similar to NT 
> vs Cygwin, etc. That is a bit beyond my skills, and I have no way of 
> testing those systems.

If you find a solution, I can help test on Windows 9x.  But first, is there any reason `DwmSetWindowAttribute' can't be dynamically loaded, like many other functions are on MS-Windows?

Re: Dark mode on Windows

[Po Lu]

Vince Salvino <salvino@coderedcorp.com> writes:

> I originally tried dynamically loading dwmapi.dll, and it cannot be
> done dynamically. It will simply not load. I spent a lot of time
> head-scratching in gdb to figure this out. From what I read, it
> behaves a bit differently than other DLLs and has to be linked. This
> is also my first foray into Win32 programming, so I have exactly zero
> experience with any of this stuff, and could be wrong.

Some searching reveals that dwmapi.dll is apparently already loaded into
every program on systems that have it.

So you probably just need a way to get the address of the symbol for the
function you want to use.

But I don't know much about programming for MS-Windows, so I'm afraid I
can't help more.

Thanks.

Re: Dark mode on Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Mon, 25 Oct 2021 14:25:38 +0800
> 
> Vince Salvino <salvino@coderedcorp.com> writes:
> 
> > I originally tried dynamically loading dwmapi.dll, and it cannot be
> > done dynamically. It will simply not load. I spent a lot of time
> > head-scratching in gdb to figure this out. From what I read, it
> > behaves a bit differently than other DLLs and has to be linked. This
> > is also my first foray into Win32 programming, so I have exactly zero
> > experience with any of this stuff, and could be wrong.
> 
> Some searching reveals that dwmapi.dll is apparently already loaded into
> every program on systems that have it.

If it is already loaded, LoadLibrary should just increase its
reference count, but will return a valid handle.  We do that all the
time in Emacs, for example when using LoadLibrary to load
kernel32.dll, which on modern Windows systems is always loaded.

> So you probably just need a way to get the address of the symbol for the
> function you want to use.

You cannot get an address without a handle to the DLL, and that's what
LoadLibrary gives you.  An alternative is to use GetModuleHandle, if
we know the library is already loaded.

The main point is that if we link with -ldmwapi, i.e. link statically
against the DLL, the resulting Emacs binary will refuse to start on
systems where this DLL is not available.  So this means in practice we
will be unable to provide precompiled binaries that run on any
supported Windows system.

RE: Dark mode on Windows

[Vince Salvino]

Thanks for the suggestions Eli and Po. I tried GetModuleHandle, and did in fact run into the error that you cannot GetModuleHandle if the DLL is not already loaded (it returns 0x0). For some reason this worked with uxtheme.dll (I'm guessing something must have inadvertently loaded it as a side effect?), but not with dwmapi.dll. I will try LoadLibrary and see if that works.

I understand that linking -ldwmapi will shut out XP and earlier, so am trying to find a solution around that. Will report back with any findings after playing with it a bit.

Vince Salvino

-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org> 
Sent: Monday, October 25, 2021 8:38 AM
To: Po Lu <luangruo@yahoo.com>
Cc: Vince Salvino <salvino@coderedcorp.com>; emacs-devel@gnu.org
Subject: Re: Dark mode on Windows

> From: Po Lu <luangruo@yahoo.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Mon, 25 Oct 2021 14:25:38 +0800
> 
> Vince Salvino <salvino@coderedcorp.com> writes:
> 
> > I originally tried dynamically loading dwmapi.dll, and it cannot be 
> > done dynamically. It will simply not load. I spent a lot of time 
> > head-scratching in gdb to figure this out. From what I read, it 
> > behaves a bit differently than other DLLs and has to be linked. This 
> > is also my first foray into Win32 programming, so I have exactly 
> > zero experience with any of this stuff, and could be wrong.
> 
> Some searching reveals that dwmapi.dll is apparently already loaded 
> into every program on systems that have it.

If it is already loaded, LoadLibrary should just increase its reference count, but will return a valid handle.  We do that all the time in Emacs, for example when using LoadLibrary to load kernel32.dll, which on modern Windows systems is always loaded.

> So you probably just need a way to get the address of the symbol for 
> the function you want to use.

You cannot get an address without a handle to the DLL, and that's what LoadLibrary gives you.  An alternative is to use GetModuleHandle, if we know the library is already loaded.

The main point is that if we link with -ldmwapi, i.e. link statically against the DLL, the resulting Emacs binary will refuse to start on systems where this DLL is not available.  So this means in practice we will be unable to provide precompiled binaries that run on any supported Windows system.

Re: Dark mode on Windows

[Eli Zaretskii]

> From: Vince Salvino <salvino@coderedcorp.com>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Mon, 25 Oct 2021 15:44:05 +0000
> 
> I understand that linking -ldwmapi will shut out XP and earlier, so am trying to find a solution around that. Will report back with any findings after playing with it a bit.

We already have the solution for that, and we use it with many
features that are only available on newer Windows versions.  There are
many examples in w32*.c files, but just to give you one such example,
look at w32.c:open_process_token, which is used to call
OpenProcessToken when it's available and gracefully report failure
when it isn't.

If you need several functions from dwmapi.dll, not just one, try using
the DEF_DLL_FN and LOAD_DLL_FN macros; a good example is in
w32uniscribe.c, where we dynamically load HarfBuzz if it's installed.

Re: Dark mode on Windows

[Eli Zaretskii]

> From: Vince Salvino <salvino@coderedcorp.com>
> Date: Mon, 25 Oct 2021 05:20:43 +0000
> Accept-Language: en-US
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> I originally tried dynamically loading dwmapi.dll, and it cannot be done dynamically. It will simply not load. I spent a lot of time head-scratching in gdb to figure this out. From what I read, it behaves a bit differently than other DLLs and has to be linked. This is also my first foray into Win32 programming, so I have exactly zero experience with any of this stuff, and could be wrong.

Can you tell the details of what you tried, and what you saw when you
tried that?  What does it mean "will not load"?  Does LoadLibrary
return NULL or a handle that cannot be used?  If so, what does
GetLastError return when that happens?  And when LoadLibrary fails,
does GetModuleHandle return a valid handle (which would indicate that
the DLL is already loaded into the program's address space)?  And
finally, if you run Emacs under GDB, does the "info shared" command in
GDB show dwmapi.dll as loaded?

Re: Dark mode on Windows

[Eric S Fraga]

On Monday, 25 Oct 2021 at 04:14, Vince Salvino wrote:
> Other operating systems have their own window managers, which actually
> are user-controllable, and would not require such a kludge in emacs :)

And exwm doesn't even have title bars for its windows... ;-)

-- 
Eric S Fraga via Emacs 28.0.60 & org 9.5 on Debian 11.1

Re: Dark mode on Windows

[Alan Third]

On Mon, Oct 25, 2021 at 09:17:50AM +0800, Po Lu wrote:
> P.S. this is also a problem with the NS port.  The ability to use a dark
> stylesheet for window decorations is only available on macOS, and not
> GNUstep.

See bug#47291 and the discussion here:

    https://lists.gnu.org/archive/html/emacs-devel/2021-03/msg00482.html

There was some discussion of tying this into some pre-existing GTK
behaviour that derailed the entire thing and I don't know where we are
with it now.
-- 
Alan Third

Re: Dark mode on Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Mon, 25 Oct 2021 09:17:50 +0800
> 
> Vince Salvino <salvino@coderedcorp.com> writes:
> 
> > Here is a work in progress, which seemingly works quite well, but
> > needs a bit more work. Would anyone be able to help, or possibly help
> > get such a feature merged in?
> 
> Is this feature available on free operating systems?
> 
> The X11+GTK port, which runs on free operating systems, needs this
> feature.

AFAIK, in the GTK build the GTK itself determines how the decorations
look, and it does that according to the system theme.  We also support
GSettings.

Re: Dark mode on Windows

[Stefan Monnier]

Eli Zaretskii [2021-10-25 14:55:54] wrote:
>> From: Po Lu <luangruo@yahoo.com>
>> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> Date: Mon, 25 Oct 2021 09:17:50 +0800
>> 
>> Vince Salvino <salvino@coderedcorp.com> writes:
>> 
>> > Here is a work in progress, which seemingly works quite well, but
>> > needs a bit more work. Would anyone be able to help, or possibly help
>> > get such a feature merged in?
>> 
>> Is this feature available on free operating systems?
>> 
>> The X11+GTK port, which runs on free operating systems, needs this
>> feature.
>
> AFAIK, in the GTK build the GTK itself determines how the decorations
> look, and it does that according to the system theme.  We also support
> GSettings.

But we still need to re-set the `frame-background-mode` when the
environment changes from dark to light and vice-versa, right?


        Stefan

Re: Dark mode on Windows

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Po Lu <luangruo@yahoo.com>,  salvino@coderedcorp.com,  emacs-devel@gnu.org
> Date: Mon, 25 Oct 2021 08:22:43 -0400
> 
> Eli Zaretskii [2021-10-25 14:55:54] wrote:
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> >> Date: Mon, 25 Oct 2021 09:17:50 +0800
> >> 
> >> Vince Salvino <salvino@coderedcorp.com> writes:
> >> 
> >> > Here is a work in progress, which seemingly works quite well, but
> >> > needs a bit more work. Would anyone be able to help, or possibly help
> >> > get such a feature merged in?
> >> 
> >> Is this feature available on free operating systems?
> >> 
> >> The X11+GTK port, which runs on free operating systems, needs this
> >> feature.
> >
> > AFAIK, in the GTK build the GTK itself determines how the decorations
> > look, and it does that according to the system theme.  We also support
> > GSettings.
> 
> But we still need to re-set the `frame-background-mode` when the
> environment changes from dark to light and vice-versa, right?

Nothing a timer cannot handle, AFAIU.

Btw, what about D-bus: doesn't it already allow us to act upon such
events?

Re: Dark mode on Windows

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi,

>> But we still need to re-set the `frame-background-mode` when the
>> environment changes from dark to light and vice-versa, right?
>
> Nothing a timer cannot handle, AFAIU.
>
> Btw, what about D-bus: doesn't it already allow us to act upon such
> events?

Just checked on my Fedora 34 + GNOME 40. Toggling between Adwaita and
Adwaita-dark doesn't fire a respective D-Bus event.

Best regards, Michael.

Re: Dark mode on Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Btw, what about D-bus: doesn't it already allow us to act upon such
> events?

D-Bus is useless here, but GtkSettings provides several signals that can
be used as follows:

  GtkSettings *gs = /* get a GtkSettings object */.
  g_signal_connect (G_OBJECT (gs), "notify::gtk-theme-name",
		    G_CALLBACK (style_change_cb), userdata);
  g_signal_connect (G_OBJECT (gs), "notify::gtk-application-prefer-dark-theme",
		    G_CALLBACK (style_change_cb), userdata);

Re: Dark mode on Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  salvino@coderedcorp.com,
>   emacs-devel@gnu.org
> Date: Tue, 26 Oct 2021 10:04:52 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw, what about D-bus: doesn't it already allow us to act upon such
> > events?
> 
> D-Bus is useless here, but GtkSettings provides several signals that can
> be used as follows:
> 
>   GtkSettings *gs = /* get a GtkSettings object */.
>   g_signal_connect (G_OBJECT (gs), "notify::gtk-theme-name",
> 		    G_CALLBACK (style_change_cb), userdata);
>   g_signal_connect (G_OBJECT (gs), "notify::gtk-application-prefer-dark-theme",
> 		    G_CALLBACK (style_change_cb), userdata);

Like I said: this is already available, or can be easily added.
Right?

Re: Dark mode on Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Like I said: this is already available, or can be easily added.
> Right?

Yeah, that's correct.  But I think someone will have to do the work to
expose it to Lisp code.

Perhaps exposing GtkSettings to Lisp would be worth some consideration.

Thanks.

Re: Dark mode on Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: salvino@coderedcorp.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Tue, 26 Oct 2021 21:35:47 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Like I said: this is already available, or can be easily added.
> > Right?
> 
> Yeah, that's correct.  But I think someone will have to do the work to
> expose it to Lisp code.
> 
> Perhaps exposing GtkSettings to Lisp would be worth some consideration.

Patches are welcome to add that.

Re: Dark mode on Windows

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> AFAIK, in the GTK build the GTK itself determines how the decorations
>> look, and it does that according to the system theme.  We also support
>> GSettings.
>
> But we still need to re-set the `frame-background-mode` when the
> environment changes from dark to light and vice-versa, right?

This is about the frame's titlebar, not the frame's contents.

The issue here is that on MS Windows the application has control over
the titlebar's appearence. When the user switches to dark mode in the OS
settings, the applications themselves must change the window
decorations. Currently Emacs ignores that. This patch adapts the title
frame colors to the the OS light/dark setting.

Re: Dark mode on Windows

[Stefan Monnier]

Óscar Fuentes [2021-10-25 15:02:59] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> AFAIK, in the GTK build the GTK itself determines how the decorations
>>> look, and it does that according to the system theme.  We also support
>>> GSettings.
>> But we still need to re-set the `frame-background-mode` when the
>> environment changes from dark to light and vice-versa, right?
> This is about the frame's titlebar, not the frame's contents.

But the user's expectation is presumably that the rest
also switches to a light-text-on-dark-background, no?


        Stefan

Re: Dark mode on Windows

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> But we still need to re-set the `frame-background-mode` when the
>>> environment changes from dark to light and vice-versa, right?
>> This is about the frame's titlebar, not the frame's contents.
>
> But the user's expectation is presumably that the rest
> also switches to a light-text-on-dark-background, no?

Maybe, maybe not. On some machines I always use a dark theme on Emacs
independently of the OS theme. And we need a relation from dark/light
themes to light/dark themes, etc

Anyways, if this patch inspires further functionality, great, but it is
useful as it is. It would be a waste if the thread turns into a
discussion about generalized features, cross-platform support and the
meaning of life in general.

Re: Dark mode on Windows

[Stefan Monnier]

> Maybe, maybe not. On some machines I always use a dark theme on Emacs
> independently of the OS theme. And we need a relation from dark/light
> themes to light/dark themes, etc

Indeed, there needs to be extra config here.

> Anyways, if this patch inspires further functionality, great, but it is
> useful as it is.

Right.  The only important thing is for the OS's switch to trigger some
hook in ELisp so that the "further functionality" can be implemented.


        Stefan

Re: Dark mode on Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> AFAIK, in the GTK build the GTK itself determines how the decorations
> look, and it does that according to the system theme.  We also support
> GSettings.

I wasn't talking about toolkit decorations in general, but the window
decorations.  As they stand, they are determined by the window manager,
but GTK provides the ability to force the use of client side
decorations, where GTK (and programs) can then modify the style used for
the decorations manually.

Re: Dark mode on Windows

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> AFAIK, in the GTK build the GTK itself determines how the decorations
>> look, and it does that according to the system theme.  We also support
>> GSettings.
>
> I wasn't talking about toolkit decorations in general, but the window
> decorations.  As they stand, they are determined by the window manager,
> but GTK provides the ability to force the use of client side
> decorations, where GTK (and programs) can then modify the style used for
> the decorations manually.

That's not relevant here. IIUC when the user configures Gnome for using
a dark theme, the setting becomes effective to window decorations,
including the window title bar.

Windows 10 dark theme *needs* the collaboration of the application for
applying the setting to the title bar.

Re: Dark mode on Windows

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> That's not relevant here. IIUC when the user configures Gnome for using
> a dark theme, the setting becomes effective to window decorations,
> including the window title bar.

But that means it can't be configured on a per-frame basis, which is
possible in the NS port.

Re: Dark mode on Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 26 Oct 2021 10:02:03 +0800
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > That's not relevant here. IIUC when the user configures Gnome for using
> > a dark theme, the setting becomes effective to window decorations,
> > including the window title bar.
> 
> But that means it can't be configured on a per-frame basis, which is
> possible in the NS port.

Why is that an issue?  Different ports have slightly different
behaviors, because the underlying platforms are different.

Re: Dark mode on Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Why is that an issue?  Different ports have slightly different
> behaviors, because the underlying platforms are different.

In many contexts, it would make sense to set the decoration color of
frames on a per-frame basis.  For instance, I recall a package that
applied per-frame theming named "NANO theme" landing on ELPA recently,
that would greatly benefit from this feature.

Re: Dark mode on Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Wed, 27 Oct 2021 08:36:16 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why is that an issue?  Different ports have slightly different
> > behaviors, because the underlying platforms are different.
> 
> In many contexts, it would make sense to set the decoration color of
> frames on a per-frame basis.  For instance, I recall a package that
> applied per-frame theming named "NANO theme" landing on ELPA recently,
> that would greatly benefit from this feature.

One step at a time, okay?

Re: Dark mode on Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: salvino@coderedcorp.com,  emacs-devel@gnu.org
> Date: Tue, 26 Oct 2021 08:56:35 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > AFAIK, in the GTK build the GTK itself determines how the decorations
> > look, and it does that according to the system theme.  We also support
> > GSettings.
> 
> I wasn't talking about toolkit decorations in general, but the window
> decorations.  As they stand, they are determined by the window manager,
> but GTK provides the ability to force the use of client side
> decorations, where GTK (and programs) can then modify the style used for
> the decorations manually.

So AFAIU we are in agreement: the proposed patch enables on MS-Windows
what is already available with GTK.  Right?

Re: Dark mode on Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> I wasn't talking about toolkit decorations in general, but the window
>> decorations.  As they stand, they are determined by the window manager,
>> but GTK provides the ability to force the use of client side
>> decorations, where GTK (and programs) can then modify the style used for
>> the decorations manually.

> So AFAIU we are in agreement: the proposed patch enables on MS-Windows
> what is already available with GTK.  Right?

Well, not exactly: nobody has made Emacs take advantage of the features
provided by GTK yet.

Re: Dark mode on Windows

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Is this feature available on free operating systems?

Thanks for raising that point -- it is pertinent.
However, I think there is no big difficulty
in making this work on all systems.

For instance, Emacs could define a system-independent way to specify
"dark mode".  Perhaps using an environment variable.  I'd expect that
to work on all systems.  If a system has a conventional way
to specify this. then Emacs should recognize it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: Dark mode on Windows

[Vince Salvino]

> For instance, Emacs could define a system-independent way to specify "dark mode".  Perhaps using an environment variable.  I'd expect that to work on all systems.  If a system has a conventional way to specify this. then Emacs should recognize it.

I agree this would be a fun feature, so that users could then customize their own configuration around the system variable. However this particular patch does not add any new features, it is simply making the GUI on MS-Windows more consistent with the other supported window managers. Users of free operating systems already enjoy this feature :)  For example, in Emacs 27.2:

* GTK: Changing the GTK theme (e.g. adwaita to adwaita-dark): the title bar of Emacs GUI is now dark, following the GTK theme (controlled by window manager).

* macOS: changing the system preference from light to dark: the title bar of Emacs GUI is now dark, following the macOS system preference (controlled by window manager).

* MS-Windows: changing the system preference from light to dark: the title bar of Emacs GUI remains white, even though the system theme is dark (the window manager requires opt-in from the program to respect the system preference). This patch fixes that behavior by providing the necessary opt-in to respect the system setting.

I will try to make a second patch following your advice, independent of this patch, which exposes the system light/dark preference to Emacs, via a variable, so that the user can read or write it at their pleasure. This is going to require knowledge of all the various window managers supported by Emacs, so help will be appreciated!

Vince Salvino

Re: Dark mode on Windows

[Óscar Fuentes]

Vince Salvino <salvino@coderedcorp.com> writes:

> I will try to make a second patch following your advice, independent
> of this patch, which exposes the system light/dark preference to
> Emacs, via a variable, so that the user can read or write it at their
> pleasure. This is going to require knowledge of all the various window
> managers supported by Emacs, so help will be appreciated!

What you propose makes no sense, in general. In KDE, for instance, there
is no light <-> dark switch button, the user just activates wathever
theme he wants. And most window managers do not try to manage
application appearence at all, which is fine, because that's not their
job. KDE, Gnome and a few more are desktop environments and frameworks,
which have much wider scope, but you don't need one of those to run an
effective GUI on GNU/Linux.

Going back to your patch, it is okay. This thread was muddled by some
interventions who showed no understanding of the topic. You must care
only about Eli, you don't need to cater to anybody else's requests, much
less when it is obvious that they don't understand the topic (nor even
are they the target users!)

Re: Dark mode on Windows

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 27 Oct 2021 21:49:43 +0200
> 
> Going back to your patch, it is okay. This thread was muddled by some
> interventions who showed no understanding of the topic. You must care
> only about Eli, you don't need to cater to anybody else's requests, much
> less when it is obvious that they don't understand the topic (nor even
> are they the target users!)

We are waiting for Vince's legal paperwork to be completed, and then
the changes will be installed.

I think we should add support for changing the system theme after
Emacs was started, if that's possible.  There's a WM message to that
effect, AFAICT; the problem is that the way the code was written by
Vince, it only uses the theme at frame creation time, so we need to
figure out how to change the appearance of an existing frame.

Re: Dark mode on Windows

[Óscar Fuentes]

Vince Salvino <salvino@coderedcorp.com> writes:

> Windows 10 has a system-wide "dark mode", which if supported by an
> app, can tell the app to use dark title bars, scrollbars, etc.

Thanks for your work.

First of all, emacs-devel is the wrong place for discussing code
contributions, because topics are easily forgotten. Use M-x
report-emacs-bug and include a patch with what you have so far, explain
what's missing and the parts you need help with.

For more specific and extensive guidelines, see the file CONTRIBUTE in
Emacs' source distribution.

Thanks again.

RE: Dark mode on Windows

[Vince Salvino]

Thanks for the tip. I will be sure to report the patch once I have it working a bit better... there have already been some helpful suggestions in this thread.

Vince Salvino

-----Original Message-----
From: Óscar Fuentes <ofv@wanadoo.es> 
Sent: Monday, October 25, 2021 8:43 AM
To: Vince Salvino <salvino@coderedcorp.com>
Cc: emacs-devel@gnu.org
Subject: Re: Dark mode on Windows

Vince Salvino <salvino@coderedcorp.com> writes:

> Windows 10 has a system-wide "dark mode", which if supported by an 
> app, can tell the app to use dark title bars, scrollbars, etc.

Thanks for your work.

First of all, emacs-devel is the wrong place for discussing code contributions, because topics are easily forgotten. Use M-x report-emacs-bug and include a patch with what you have so far, explain what's missing and the parts you need help with.

For more specific and extensive guidelines, see the file CONTRIBUTE in Emacs' source distribution.

Thanks again.

RE: Dark mode on Windows

[Vince Salvino]

All right everyone, thanks for all your help. I managed to work out the library loading issue, and now have it querying the preferred theme from the registry. I will submit shortly following the CONTRIBUTE guide.

Info and download: https://github.com/vsalvino/emacs

Patch: https://github.com/vsalvino/emacs/pull/1/files

It currently works as so:
* Queries if emacs is running on a supported version of Windows, and OS theme is set to "dark" (light is default).
* Applies system dark title bar
* Applies system dark scroll bars

The following is needed to "complete" the dark mode, but requires a lot more rabbit holes, so will have to be saved for a later date:
* Dark menu bar (no idea how to do this)
* Dark tool bar (probably same implementation as menu bar)

Feel free to debate among yourselves as to the meaning of life:
* Automatically switching the faces/theme to a light/dark theme. This would be cool but also kind of useless as most people configure their own theme anyhow. And nearly every other editor DOES NOT do this, so I think trying to automatically switch user settings is pointless. Maybe add a link on the splash screen to set your theme.
* Make sure themes support dark tab bars. Most do not style it (since it is a newer feature) so it still appears light even on a dark theme.
* I do not want to implement a watcher that receives system light/dark mode changes to dynamically update the window theme. Just restart emacs, it's not a big deal.


Vince Salvino

-----Original Message-----
From: Vince Salvino 
Sent: Sunday, October 24, 2021 6:27 PM
To: emacs-devel@gnu.org
Subject: Dark mode on Windows

Windows 10 has a system-wide "dark mode", which if supported by an app, can tell the app to use dark title bars, scrollbars, etc.

In a fit of rage after staring at the blinding white titlebar on my Emacs frame, I researched the issue and implemented "dark mode" in Emacs for Windows (the rage had been building for years).

Here is a work in progress, which seemingly works quite well, but needs a bit more work. Would anyone be able to help, or possibly help get such a feature merged in?

See README.md in my fork: https://github.com/vsalvino/emacs 


Vince Salvino

Re: Dark mode on Windows

[Po Lu]

Vince Salvino <salvino@coderedcorp.com> writes:

> * Dark tool bar (probably same implementation as menu bar)

On MS Windows, the tool-bar is displayed by Emacs.  Customizing the face
`tool-bar' should suffice.

Re: Dark mode on Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Tue, 26 Oct 2021 15:32:31 +0800
> 
> Vince Salvino <salvino@coderedcorp.com> writes:
> 
> > * Dark tool bar (probably same implementation as menu bar)
> 
> On MS Windows, the tool-bar is displayed by Emacs.  Customizing the face
> `tool-bar' should suffice.

That depends on the effect produced by using dwmapi.dll.  If it isn't
significantly prettier than customizing the background color of the
tool bar, I agree that it makes little sense to use this feature for
the tool bar.