Use WinUI 3 to rebuild

[ChenYiLins]

Using WinUI to refactor a program is a difficult thing, but it will make many operations easier. I believe that WinUI has now reached a relatively mature state. I started the work on an accidental idea. Based on the source code, I completed 66.6% of the page construction. But its workload is actually far beyond my imagination, because upgrading to Windows App Sdk makes many works easier, but some of the related code needs to be rewritten. At the same time, some codes become confused because of long-term updates.

Using WinUI to refactor the program may solve these issues: #895 #874 #702 and more

I hope I made a good start for others, more people can participate in the construction of the code, and it will be more helpful to get a complete Auto Dark Mode built by WinUI as soon as possible.

Maybe manager can create a new branch for its development. I put the current project in this repositorie. More information could see in .github/DEVELOPMENT_NOTE.md. There may be some questions not mentioned in the document, so you can ask them at any time under this issuse.

A few extra words: At the same time, I have improved the localization of English, French, Japanese and Simplified Chinese, which is believed to be helpful for many developers to test. However, the localized text can't be seamlessly switched to the new code now, so you can refer to the development documentation to make a little modification.

The following is the unfinished Page:

• WallpaperPicker
• Colorization
• Cusors
• ThemePicker

[Spiritreader]

We're aware and you're right.

But there's neither time nor resources to do a complete overhaul. We'd need more contributors, simply speaking, as Armin mostly handles the logistics side of things and I barely have enough time to maintain ADM as is.

From what I can see, you've already put a substantial amount of work into it. If you would like to continue working on an overhaul I can create a branch for you to work on and you can PR your changes.

We'd be happy to start a more in-depth conversation on this and as you said, hopefully get some more contributors on board.

[ChenYiLins]

Thanks for your reply. Indeed, it requires a lot of resources and time. As you said, it is a good idea to create a new branch to deal with it. ( ꒰｡ › . ‹ ｡꒱ )

[Jay-o-Way]

Basically #895, but much better explained 😆

[Jay-o-Way]

@ChenYiLins much respect for starting on this! My personal opinion is that it is good to start from nothing. Just to prevent any old code from being copied. It also helps developers learn the differences. I know it's a huge work, but I like the fresh-ness. Keeping new code separate is also a great idea. Also think that - by the time the new version is ready - we should call it v2.

Few quick suggestions:

• I agree using x:uid with resw looks like a good idea.
• Check out the new XAML TitleBar control in wasdk 1.7 ✨
• Keep UI details like styling as a low priority. Functionality is more important to me, and when most of the UI is working, then you can create styles where needed. Make sure to check online guidance and/or WinUI Gallery.

[ChenYiLins]

@Jay-o-Way Your suggestion is right. I'm ashamed to say, the current code is largely based on the previous code. I will try to rewrite some basic functions from scratch to better adapt to the Windows App SDK. I have some ideas about your suggestion:

• The current code does not use x:uid for localization. Instead, ResourceLoader is used as a more ingenious way to realize localization. In this way, the reuse of localized text can be realized to a great extent.
• About TitleBar control, it still has some problems. Such as: #10454, #10427. It will be a good choice when its function is stable.
• You're right, functionality should be a priority update. Although this requires more resources and time, I believe it is definitely worth it.

[ChenYiLins]

At the same time, I think it is necessary to explain the current program structure. Because the original Auto Dark Mode divides the program into many modules, decoupling each part of the program is definitely the most correct way. Now the part that uses WinUI rebuilding is Auto Dark Mode App, which corresponds to the UI part of the program. The plan may not involve other modules for the time being, because the existing code is very stable, and I hope it will not cause destructive updates.

[Jay-o-Way]

P.S.

1. I am willing to help out with the UI, if there's a clean and solid foundation.
2. I don't have much experience with ResourceLoader (versus x:Uid) but I do know x:Uid has some nice benefits too. You can set the uid once for a XAML element, and use that to set several properties. Not just text (.Text, .Header or .Content etc.) but all kinds of properties. And it's no problem to (re-)use a uid for multiple controls. might be fun to learn something new.

Just saying 😁

Example:

<!-- xaml -->
<Element x:Uid="ExampleControl">

<!-- a resources file -->
<data name="ExampleControl.Content">
  <value>Click here to open something else</value>
  <comment>{Locked="something else"}</comment>
</data>
<data name="ExampleControl.NavigateUri">
  <value>http://github.com/TestUrl"</value>
</data>

[Spiritreader]

I've created a winui3 branch to pull in changes, so feel free to open PRs on that branch.

As far as structure goes, @ChenYiLins already mentioned the modularity.

Only the ADM app should require the winui3 dependencies, as the other components are libraries and the backend (which uses some localization strings in the Adm lib package).

The existinig App is quite a mess of tech debt that I also in part inherited when I joined the project, but it seems like @ChenYiLins's current implementation aims for updating the existing code instead of rewriting the UI from scratch.

[Jay-o-Way]

I hear ya. @ChenYiLins you okay if I take a look at your repo and then send one or two PRs to share my ideas?

[ChenYiLins]

@Jay-o-Way You mentioned the benefits of using x:Uid, which is beyond doubt. At the same time, I think x:Uid aims at localization at design time. ResourceLoader can solve the problem of dynamically updating text. These two methods have their own benefits. For the existing UI, some texts that need to be updated dynamically still need the help of ResourceLoader. Therefore, the solution is:

1. x:Uid + ResourceLoader
2. Only ResourceLoader

(Personally, I think that the first method may increase the workload of localization. (p_q) )

[ChenYiLins]

@Spiritreader Thank you very much. Your words remind me that only by rewriting the UI from scratch can we effectively reduce the technical debt. It may involve changes to other components.

[ChenYiLins]

I hear ya. @ChenYiLins you okay if I take a look at your repo and then send one or two PRs to share my ideas?我听到了。 如果我看一下你的 repo，然后发送一两个 PR 来分享我的想法，你好吗？

Of course! Thank you very much.

[Spiritreader]

@Jay-o-Way You mentioned the benefits of using x:Uid, which is beyond doubt. At the same time, I think x:Uid aims at localization at design time. ResourceLoader can solve the problem of dynamically updating text. These two methods have their own benefits. For the existing UI, some texts that need to be updated dynamically still need the help of ResourceLoader. Therefore, the solution is:

1. x:Uid + ResourceLoader

2. Only ResourceLoader

(Personally, I think that the first method may increase the workload of localization. (p_q) )

We also need to figure out how to either keep the old .resx based approach, or change the service to use different localization files.

At the moment, localization is shared between backend and frontend (The backend is a tray app and has some localized strings). But I'm also not sure if this is a good idea or if that even works properly with WinUI3

Also, due to appx/msix constriants, the WinAppSDK must be shipped as standalone (unpackaged). The service cannot run in an emulated environment as it needs to access and modify HKLM registry keys and call unsanctioned Windows private APIs

[Spiritreader]

I've made a couple of changes to the initial PR such that it integrates with the existing project structure while still allowing the new Winui3 app to run.

There seem to be dll compatibility issues when attempting to build all modules into the same output directory, maybe one of you knows what the issue is.

But the service and the app should now run simultaneously again.

[ChenYiLins]

We also need to figure out how to either keep the old .resx based approach, or change the service to use different localization files.

At the moment, localization is shared between backend and frontend (The backend is a tray app and has some localized strings). But I'm also not sure if this is a good idea or if that even works properly with WinUI3

Also, due to appx/msix constriants, the WinAppSDK must be shipped as standalone (unpackaged). The service cannot run in an emulated environment as it needs to access and modify HKLM registry keys and call unsanctioned Windows private APIs

I didn't pay attention to the effect of the old .resx on backend. I will try to find ways to share localization. At the same time, it is not difficult to use WinUI3 to realize a more modern tray app.

To be honest, I don't like msix very much. It is mixed advantage and disadvantage, we have to give up supporting msix because of many annoying restrictions.

I've made a couple of changes to the initial PR such that it integrates with the existing project structure while still allowing the new Winui3 app to run.

There seem to be dll compatibility issues when attempting to build all modules into the same output directory, maybe one of you knows what the issue is.

But the service and the app should now run simultaneously again.

The issue of compatibility requires additional review. Because I'm not sure where the problem is.

[Jay-o-Way]

@ChenYiLins I have made a lot of suggestions/changes locally, but I have a problem trying to create a PR to your fork: https://github.com/ChenYiLins/Windows-Auto-Night-Mode/compare/winui3...Jay-o-Way:Windows-Auto-Night-Mode:winui?expand=1

ChenYiLins:winui3 and Jay-o-Way:winui are entirely different commit histories.

Can you take a look at the branch and see if you can get my changes? https://github.com/Jay-o-Way/Windows-Auto-Night-Mode/tree/winui3 @Spiritreader and @Armin2208 please also take a look :)

[Spiritreader]

@Jay-o-Way The original branch by @ChenYiLins was made using a different git history.

The PR that's open now (and the one I worked on) has the correct ADM commit history. So this is why it's probably not possible to do a diff on it.

I think the only way to resolve it is to do a diff manually and push your changes again.

The repo you linked https://github.com/Jay-o-Way/Windows-Auto-Night-Mode/tree/winui3 doesn't seem to contain any new code?

At the same time, it is not difficult to use WinUI3 to realize a more modern tray app.

We would need to precisely evaluate how winui3 tray apps are launched, as right now the adm service is hooked into the lifecycle of WinForms. It's not tied into it super deep, but enough that it warrants substantial review. So I would like to hold off on that for the time being and focus on getting the frontend up to speed.

[ChenYiLins]

@Jay-o-Way As @Spiritreader said, the branch was made using a empty branch, that's my mistake. Now you could see a named "winui3" branch in my repo, it has right commit history, you can change code from this branch.

We would need to precisely evaluate how winui3 tray apps are launched, as right now the adm service is hooked into the lifecycle of WinForms. It's not tied into it super deep, but enough that it warrants substantial review. So I would like to hold off on that for the time being and focus on getting the frontend up to speed.

For sure. For components other than ADM app, the change should be postponed.

[Jay-o-Way]

The repo you linked ... doesn't seem to contain any new code?

Yeah, I re-cloned the whole thing. Working on it this very moment!

[Spiritreader]

The latest Winui3 branch has been pushed to the Beta channel and should be available from now on (beta build version 11.0.0.2)

[Spiritreader]

To provide an update for this: https://github.com/AutoDarkMode/Windows-Auto-Night-Mode/issues/999 is about to be resolved.

And https://github.com/AutoDarkMode/Windows-Auto-Night-Mode/issues/1028 is the last remaining task for the winui3 rewrite. After that, the only roadblocker that prevents us from releasing v11 is testing and fixing remaining bugs that pop up.

We can then potentially even release V11 before PowerToys adds their own (albeit way more limited) switcher