light/dark mode switch based key, on time or sunset/sunrise

[zacbowden]

An option inside Power Toys that automatically switches between Windows 10's light and dark theme at a certain time of day, or at sunset and sunrise, similar to how Night Light does in Windows 10. Feature could also be configurable so that the user can choose to have the automated process switch only app theme, or both app and system theme.

[crutkas]

We're prioritizing v1 work items but if a community member wants to help build this out, happy to dedicate time to this.

[niels9001]

Really like this idea! Here's a mock-up for the settings screen this feature would need to have.

XAML source (WinUI 3.0 Alpha) in this repo: https://github.com/niels9001/PowerToysUXWinUI3Alpha

[ismaelestalayo]

It’d also be very nice if we could choose two existing themes and set each one for day/night time (so not only the Light/Dark theme is changed, but also the wallpaper)

[niels9001]

Somebody referenced this project that does this: https://github.com/Armin2208/Windows-Auto-Night-Mode

[crutkas]

Cool project but that is GPL v3. We cannot use any source code from that project due to that license.

[mikeparkie]

I do this in EventGhost using registry and cmd. Just chipping in case it helps.

Light: REG ADD "HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize" /V AppsUseLightTheme /T REG_DWORD /D 1 /F

CMD: "%localappdata%\Microsoft\Windows\Themes\Day.theme"

Dark: REG ADD "HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize" /V AppsUseLightTheme /T REG_DWORD /D 0 /F

CMD: "%localappdata%\Microsoft\Windows\Themes\Night.theme"

[crutkas]

Thanks @mikeparkie! Investigation is a massive part of the work!!!

[bradleybowman]

I also use the exact commands @mikeparkie referenced. I think I found them through a Google search, but I can confirm it works.

I use Task Scheduler; the action is 'Start a Program', command reg, with the argument set for light/dark theme. Granted, this is just a timed trigger.

One quirk I've noticed with this method: if you leave a File Explorer window open during the change, most of the Explorer UI honors the switch--the 'folder contents' portion of the window does not. It requires closing the File Explorer window and opening a new one to produce the expected result of a fully themed Explorer window.

Point is, it works, but it's not always elegant (not sure if it's possible to force reload the open windows entirely?)

[mikeparkie]

@bradleybowman agreed, it's relatively crude in it's execution, but it works for the most part. And actually I didn't face any issues with the UI, other than the ribbon redraws first, followed by the rest of the frame/contents, take about 2 seconds in total. Enough to notice a transition.

If it's a content/icon refresh, then theres always the "ie4uinit.exe -show" command which should reload the icon cache (but I'm guessing a little there).

[BradleyBartlett]

Wrong @ in the comment

[mikeparkie]

@BradleyBartlett whoopsie, sorry about that :)

[niels9001]

Luna is a new project up on GitHub that does this.. Light-weight and made with WPF. MIT license (@crutkas)

https://github.com/adrianmteo/Luna

[bradleybowman]

@mikeparkie I noticed last night when the theme switched, it did redraw the File Explorer window properly. It's probably worth noting I'm on the 'Insider Fast Ring', so there's always the factor that I'm on a potentially unstable build.

@niels9001 I checked out Luna. The interface is slick and in my opinion just how an average end user would like to set up light/dark mode switching

If you check through that project though, it's essentially doing the same thing I am. Luna creates the Task Scheduler tasks at the times you select, and if you check out Luna/Helpers/RegistryHandler.cs:

(Hopefully I'm allowed to crosspost this, if not please let me know and I'll remove)

public static void AppsUseLightTheme(bool enabled)
        {
            RegistryKey key = Registry.CurrentUser.OpenSubKey(@"Software\Microsoft\Windows\CurrentVersion\Themes\Personalize", true);

            if (key != null)
            {
                key.SetValue("AppsUseLightTheme", enabled ? 1 : 0, RegistryValueKind.DWord);
            }
        }

^ It uses the same method that Mike and I mentioned.

Nothing against the Luna app, I really do like the interface...it just seems that, at present, theme switching falls into the 'registry hack not-elegant-but-it-works' category

[mikeparkie]

@bradleybowman likewise, I'm also running fast ring insider builds. I can't whether my previous non-insider builds had the issue or not. I'm not rebuilding to test it out :)

[niels9001]

@bradleybowman No problem, I'm excited about this. It's a 'small' feature but I think a lot of users would be happy with it. Are you guys planning to pick this up? I'd be happy to help with the XAML/UX within Settings.

[Cossey]

As others have mentioned above I also use the Registry value triggered at specific times in the task scheduler to toggle on dark mode at night.

However - I also use this registry key as well to make sure dark/light mode is applied to Windows:

REG ADD "HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize" /V SystemUsesLightTheme /T REG_DWORD /D 1 /F

[Armin2208]

Cool project but that is GPL v3. We cannot use any source code from that project due to that license.

Hello! I am the developer of the Auto Dark Mode App for Windows. I am interested in working together as I could change the license. Especially creating a new public theming API would be in the interest of all of us. In return of sharing my code with you I need some help. How can I contact you?

[niels9001]

cc @crutkas

[crutkas]

@armin2208, lets chat! crutkas@microsoft.com

[Jay-o-Way]

I had the exact same idea (connecting light/dark theme to Nightlight) a while ago. I sent in the suggestion via Windows Feedback hub. Seems like the best place for this idea, to me - really hoping it'll make it's way into Windows some day. But when Windows itself does not have this option, PowerToys looks like a good alternative.

[Armin2208]

Any news? Looking forward to this.

Firstly, we have agreed for a solution. Auto Dark Mode will be a part of PowerToys in the future.

But this feature will be a post-release feature. The PowerToys team is busy with finalizing their current work, while we are busy to improve our new theme switch engine. And the Auto Dark Mode team has a little break ;)

You can expect this feature in a PowerToys Beta in november or december.

[niels9001]

@Armin2208 any news on this :)?

[Armin2208]

no

[Jay-o-Way]

By the way, I've read requests in the Win Feedback to connect the light/dark mode to (the timing of) the nightlight function and apparently MS is really considering this. https://aka.ms/AAanro0

[tiziodcaio]

By the way, I've read requests in the Win Feedback to connect the light/dark mode to (the timing of) the nightlight function and MS is really considering this.

Yey that would be the best thing

[krysjez]

Paging @Armin2208 - you should add your project to PowerToys!

[IndefiniteBen]

@crutkas Any update on this please? I just installed Auto-Night-Mode for now, but it'd be nice to be in the PowerToys package too.

[crutkas]

@IndefiniteBen not something we've added in, we have the help wanted tag. @Armin2208 was interested in adding it in.

[Armin2208]

yes I wanted to add this as post release feature. But we all know Power Toys 1.0 was delayed. But I will probably add this earlier then :D no worries.

[ghost]

This would be a great feature to have @Armin2208 Please let us know if there's been any progress or if you have your plate full and help is still wanted

[Armin2208]

This would be a great feature to have @Armin2208 Please let us know if there's been any progress or if you have your plate full and help is still wanted

could you help me with implementing sunrise and sunset time calculation? currently I use third party code with a not suitable license. this method needs a rewrite.

[niels9001]

@armin2208 If you need any help with UI/XAML stuff, let me know!

[ghost]

could you help me with implementing sunrise and sunset time calculation? currently I use third party code with a not suitable license. this method needs a rewrite.

So ideally I would attempt using the same method Windows itself uses for its "Night light schedule" calculation whose, well, I don't know which is. If Windows made those values available somewhere on the registry that would be a good starting place to check, as chances are the Weather API Windows uses is proprietary.

And in that matter I don't think we have much luck. Besides needing an API-key we would be facing limitations for pretty much any Weather API. And in my humble opinion I don't think an automatic sunrise-sunset schedule is a priority for the feature.

Would be good to hear what others think.

[krysjez]

This product manager agrees that auto-sunrise/sunset is a secondary priority :)

On Tue, Apr 13, 2021 at 9:50 AM Andrey Érick @.***> wrote:

could you help me with implementing sunrise and sunset time calculation? currently I use third party code with a not suitable license. this method needs a rewrite.

So ideally I would attempt using the same method Windows itself uses for its "Night light schedule" calculation whose, well, I don't know which is. If Windows made those values available somewhere on the registry that would be a good starting place to check, as chances are the Weather API Windows uses is proprietary.

And in that matter I don't think we have much luck. Besides needing an API-key we would be facing limitations for pretty much any Weather API. And in my humble opinion I don't think an automatic sunrise-sunset schedule is a priority for the feature.

Would be good to hear what others think.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/microsoft/PowerToys/issues/1331#issuecomment-818752053, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEXNOVUFSOFDJ2L6FFGPY3TIRD3VANCNFSM4KYCWURQ .

[crutkas]

I think for this feature we need crisp understanding of

• how sunrise / sunset are being calculated
• What API is being used to change the theme (bonus points if we can directly link to docs.msft page 😊)

[Spiritreader]

@crutkas As a collaborator/team member for ADM I can provide some clarification:

Sun Times

I think for this feature we need crisp understanding of

• how sunrise / sunset are being calculated

Sun times are calculated with geodata (lat, lon) using Windows.Devices.Geolocation as seen here. We are already using windows native APIs to do that, I think that should satisfy @andreyrk's concern.

In order to derive sunrise and sunset from latitude and longitude we need the Sunrise Equation. In AutoDarkMode, we currently use a GPL 3.0 licensed C# port.

The original source was written in C and was released to the public domain. You can find that here! If someone ported that to C# under a MIT license I believe that would work?

Theme change API

• What API is being used to change the theme (bonus points if we can directly link to docs.msft page 😊)

There are two types of supported theme switching flows in ADM:

1. Manually changing as much as possible

We generally consider this the "legacy" option as the other option is more convenient and can apply Windows Themes). The way this functions is by editing aspects of the UI via registry. This is exposed in the RegistryHandler and supports:

• AppsTheme
• SystemTheme
• ColorPrevalence

In addition to that it is also possible to set the wallpaper using the win32 API's SystemParametersInfo

2. Using @kuchienkz discovery with KAWAII theme switcher on how to set a Windows Theme programmatically.

It has a "free to use as long as credited and the software remains free to use" license if I understand it correctly. We basically took that and put a com wrapper thread around it (mainly because we don't know how this works, our specialization doesn't lie there)

It used GUID com imports so we have no idea where the API is coming from except from the DLLs listed.

I believe the original policy was "no private APIs for PowerToys", as such we considered this a non-option and opted to plan to remove it for the "minimized" version of ADM that is then potentially suited for a PowerToys implementation. Generally though, this solution would be ideal because creating themes with Windows Settings and then applying them using ADM is less confusing and more integrated.

[ghost]

The general complaint about switching themes programmatically is launching the themefiles opens the Windows customization settings page. I figured one could maybe trick it to not open up by launching through a different program that can handle the low-level side of things. I assume that's related to what KAWAII theme switcher is doing.

There is quite a lot of magic going on in that code but the important part in my view is the DllImport of UxTheme.dll for the SetSystemVisualStyle function (which is a custom name for the function at ordinal 65) but there is no ordinal 65 for that .dll at least on my system. Themes also include changes to sounds which I'm unsure if that function does as well. But I'll be playing around with that tomorrow.

It would simply be best for Windows not to open the settings when someone launches a themefile, but there's been a few feature requests on that by unrelated people and apparently no progress so far.

[Armin2208]

beside of that, where are requests to only partial apply themes. Some people want to change their system, app theme and accent color, but not the desktop wallpaper.

This is a more complex implementation of theme files, but I've seen one tool that does this job. But completely closed source.

[niels9001]

I think the initial ask is about switching between dark and light mode based on sunrise/sunset (or other predefined time), very similar to what Night Light does. This helps users to not have fully lid/bright screens when in darker environments.

This is different then changing visual Windows themes or wallpapers. IMO, it would help to come up with a (small) specification on what this feature should do in a first version.

[Spiritreader]

I think the initial ask is about switching between dark and light mode based on sunrise/sunset (or other predefined time), very similar to what Night Light does. This helps users to not have fully lid/bright screens when in darker environments.

This is different then changing visual Windows themes or wallpapers. IMO, it would help to come up with a (small) specification on what this feature should do in a first version.

That is a fantastic idea. What is the minimum complete definition of a night/day switch for power toys?

I would suggest that as a starting point at least the following elements would need to switch:

• System Theme
• Apps theme

Then there's color prevalence which modifies the taskbar color. Is that considered an option for night / day modes or is that already considered theme switching?

[niels9001]

@spiritreader Yeah, it's basically about automating (and/or scheduling) these two settings as an original ask:

Changing the taskbar color, accent color or themes are a separate ask I think.

[krysjez]

I would suggest everyone (new) interested in this to check out @armin2208 and @spiritreader's Auto Dark Mode project first - they've done some great work that accomplishes this ask nicely, which is why I suggested they look at integrating it into PowerToys :)

If we need a mini spec, how about the following proposal for an initial release:

1. Allow user to specify two HH:MM times - "Light mode begins at x"; "Dark mode begins at y".
2. Between x and y, set both the default Windows mode and default app mode to "Light".
3. Between y and x, set both the default Windows mode and default app mode to "Dark".

This adds two improvements to Auto Dark Mode:

1. More descriptive strings clarifying the role of the two times.
2. Ability to switch modes at any time of day, not just light mode in AM and dark mode in PM.

Finally, here is a suggested priority order for future improvements:

1. Add location-based sunrise/sunset times for light/dark mode.
2. Add support for changing Office/Edge color mode.
3. Allow user to offset auto sunrise/sunset.
4. Add granular control over which items get which color modes at the specified times - e.g. different "Windows" and "app" color modes. (Today this is implemented in the Apps tab of Auto Dark Mode.)

I agree with @niels9001 that wallpaper, accent color, themes are separate issues and should be treated accordingly.

[Armin2208]

Great thoughts and specs @krysjez!

This is also my initial plan.

The first power toys version should be pretty basic, just changing system and app theme at certain times. But I also want to have location based sun times in the first implementation. This is important. we don't need theme switching yet.

thanks to Winui3 we can easily improve the time picker. Sadly ADM can't use the new UI components yet, this is why we just have modified text boxes.

thankfully we don't need anymore to implement office and edge theme switch, because the office team now implemented automatic theme switch :)

[krysjez]

I'm passionate about location-based times too, I would just caution to not let the perfect be the enemy of the good :) We can give faster relief to thousands of tired eyes worldwide by releasing earlier with a smaller scope.

But I recognize that's just my personal approach to shipping software. I'll defer to the others here on whether location-based sunrise/sunset should be in the initial implementation.

[Spiritreader]

@krysjez From my point of view, the specification looks complete and perfectly captures the essence of what AutoDarkMode is doing.

Concerning the three modes mentioned in the proposal:

1. Allow user to specify two HH:MM times - "Light mode begins at x"; "Dark mode begins at y".

AutoDarkMode does already handle HH:MM that way if set to 24h mode. The 12h mode was/is always a bit awkward to use.

2. Between x and y, set both the default Windows mode and default app mode to "Light".
3. Between y and x, set both the default Windows mode and default app mode to "Dark".

If I understand this correctly, these two options can be used in addition to / alongside option 1?

My thoughts on location-based sundates

Implementing location-based times may not really broaden the scope by that much. The Windows Location API has proven to be easy to use and very reliable. When AutoDarkMode was refactored into a service, getting location-based times (with and without offset) to function was quite painless and worked well.

That being said, I absolutely understand the approach to ship a basic functioning implementation to ensure reliability and quicker feature delivery. In this case though, I'm inclined to agree with @Armin2208 and would be leaning more towards including location-based times.

As such, I would welcome if we also created a mini-spec to define the feature. From there, we could determine to what extent, and if at all, an inclusion of location-based sunrise/sunset times makes sense for the initial release!

Branching ADM to conform to the specification

We already have permission to branch off ADM with a powertoys-compatible license. In this step all features not mentioned in the specification will be removed (among other functionality that is not necessary for a powertoys integration). As soon as the specification is complete, we can start working on that. This way, the specialized build for ADM then reflects a demonstration of how it would function within powertoys and the suitability and steps for an integraton can be determined.

[Jay-o-Way]

I'm just hoping it doesn't end up that Microsoft is working on the same thing somewhere in the shadows. As I said, I've read requests in the Win Feedback to connect the light/dark mode to (the timing of) the nightlight function and apparently MS is considering this. Could turn out a waste of time, but that's my idea. https://aka.ms/AAanro0

[krysjez]

I'll see what I can find internally (I am unlikely to be able to share my findings here) but I would recommend going ahead with this.

[Armin2208]

I'll see what I can find internally (I am unlikely to be able to share my findings here) but I would recommend going ahead with this.

well, if you say "we don't implement this" everyone knows that Microsoft is working on this. But if you would know it and say "just do your things"... you would "waste" our time haha :D

Would be nice to know it tbh.

Or you just say the Windows team "scrap this, we make this".

[krysjez]

:)

On Wed, Apr 14, 2021, 17:50 Armin Osaj @.***> wrote:

I'll see what I can find internally (I am unlikely to be able to share my findings here) but I would recommend going ahead with this.

well, if you say "we don't implement this" everyone knows that Microsoft is working on this. But if you would know it and say "just do your things"... you would "waste" our time haha :D

Would be nice to know it tbh.

Or you just say the Windows team "scrap this, we make this".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/microsoft/PowerToys/issues/1331#issuecomment-819871146, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEXNOQAAEEZZMP3P3V3WSLTIYE2HANCNFSM4KYCWURQ .

[jwfxpr]

Sun Times

I think for this feature we need crisp understanding of

• how sunrise / sunset are being calculated

Sun times are calculated with geodata (lat, lon) using Windows.Devices.Geolocation as seen here. We are already using windows native APIs to do that, I think that should satisfy @andreyrk's concern.

In order to derive sunrise and sunset from latitude and longitude we need the Sunrise Equation. In AutoDarkMode, we currently use a GPL 3.0 licensed C# port.

The original source was written in C and was released to the public domain. You can find that here! If someone ported that to C# under a MIT license I believe that would work?

@Spiritreader, @Armin2208, I have just done an initial commit on an MIT licensed port of that sunrise/set calculator here. I've done some elementary unit testing (the unit test is in the repository) and am getting numbers that seem to be accurate to the minute. It also implements additional features from the original algorthm that the GPL 3.0 licensed implementation you're currently using doesn't (like calculating civil, nautical, or astronomical dawns and dusks), though those aren't important for your use.

One small difference is that my implementation returns DateTime objects in UTC for the sunrise and sunset values, but that should be trivially easy to refactor for you. My code should be well commented and documented, and please open any issues you want, of course. You are very welcome to use this in Windows-Auto-Night-Mode and, of course, in the PowerToy.

Hope this helps!