From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#51404: Support system dark mode on Windows 10 Date: Tue, 26 Oct 2021 20:05:04 +0300 Message-ID: <838ryfyawv.fsf@gnu.org> References: <834k93zxyo.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25118"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 51404@debbugs.gnu.org To: Vince Salvino Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 26 19:08:12 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mfPvn-0006Jw-30 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 Oct 2021 19:08:11 +0200 Original-Received: from localhost ([::1]:39342 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfPvl-0008IA-SG for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 Oct 2021 13:08:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42092) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfPtj-0006NM-1N for bug-gnu-emacs@gnu.org; Tue, 26 Oct 2021 13:06:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35894) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mfPti-0006tG-Ox for bug-gnu-emacs@gnu.org; Tue, 26 Oct 2021 13:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mfPti-0005nE-KA for bug-gnu-emacs@gnu.org; Tue, 26 Oct 2021 13:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Oct 2021 17:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51404 X-GNU-PR-Package: emacs Original-Received: via spool by 51404-submit@debbugs.gnu.org id=B51404.163526794022215 (code B ref 51404); Tue, 26 Oct 2021 17:06:02 +0000 Original-Received: (at 51404) by debbugs.gnu.org; 26 Oct 2021 17:05:40 +0000 Original-Received: from localhost ([127.0.0.1]:47439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mfPtL-0005mF-JP for submit@debbugs.gnu.org; Tue, 26 Oct 2021 13:05:39 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44676) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mfPtJ-0005m2-Ub for 51404@debbugs.gnu.org; Tue, 26 Oct 2021 13:05:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35482) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfPtC-0006pT-Iy; Tue, 26 Oct 2021 13:05:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=tH0ZACRUQa69l+CS8/IkBorb5SsdQaX2tS3NWCevcwQ=; b=L4n81o89NgtC fngNZNFM9yjW277z29O2aiWPRNl9b8RI+9SViRrQqHxyOviB5aEsY/Z1+cMZxMnUhqAv87qOtRUMq kJaCBArLy1f4M6OoAaYVFkWv88GynV0GNZfgmuL3UG5KUv99dHkEUYjnlVn/6O+BkNq9YpL+I4Lqu h+2R8MGXd69KAEZ4QVUFgu9r+7hA4vbxRvQQdP/AUG6SYEuCUSa/F48xlWtVryGvRvOhoxsGZ+d/O /KAWzKsT5S2I6ZPQzKIiUezfvlNgArf9k0ET4L3cirV4r8coxcfJgqG+wp4Wzlb/0cZ2O1SEFuoMC jwKogDmHQZcYuEjGLvZZpQ==; Original-Received: from [87.69.77.57] (port=4662 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfPsq-0004dJ-Uh; Tue, 26 Oct 2021 13:05:27 -0400 In-Reply-To: (message from Vince Salvino on Tue, 26 Oct 2021 16:49:34 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:218394 Archived-At: > From: Vince Salvino > 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.