Apply dark mode in win32 api to rufus

[memoarfaa]

This is an idea about apply DarkMode to rufus it still in progress but if you welcome it, I will finish it fix #1453

2024-06-24_19-49-08.mp4

[pbatard]

Well, it's still going to be some time before I switch Rufus UI to XAML Islands and (hopefully) get Dark Mode automatically, so, if you want to invest your time to add Dark Mode to the current GDI-based UI, and considering that I do expect to be pestered by people who want Dark Mode for quite a few more years, I definitely wouldn't mind having an intermediate solution for Rufus.

This means that, if you are willing to contribute one, I'm not going to shut you down, as long as it doesn't look like it's going to be too intrusive to the existing code, which, at first glance at your draft proposal, doesn't look like is it, and as long as you fix the MinGW build issues. So you are getting a thumbs up from me.

If it helps, I'm also going to attach the patch that I originally played with to produce my own version of dark themed Rufus, which produced the output you see below and that I posted in #1453 (Unlike you, I didn't get to sort the progress bar and backgrounds, but I did sort out the title bar, so maybe you'll find something useful, though I have to point out that this was a quick & dirty tryout and definitely not production-ready code):

For the record, this patch is meant to be applied on top of commit 129aa64, which means it was designed circa Rufus 3.10, so, obviously, the code has changed a bit since then.

[randompersononinternet69]

Still failing to build MinGW version.

[Dhyfer1]

@memoarfaa Good job 👏, it's amazing that third parties can do something that the developer himself has not been able to do. There is already an issue asking for the dark theme for Rufus but the dev is not interested, too difficult for him, but thanks to you we see that it is possible without installing external themes. Keep moving forward with this 👍

[pbatard]

but if you welcome it, I will finish it

@memoarfaa, do you still plan to finish this?

In its current state, I'm afraid that I only see an half complete pull request, that also fails to build on MinGW, and that is not something that I can integrate. And I can definitely understand how completing the work might reveal to be a lot more time consuming than you anticipated, and how you may decide not to go through with it after all, so if this is no longer something you are interested in completing, you don't have to feel pressured into doing so.

I will however have to close this PR if it doesn't see any further update (but of course, the PR can be reopened at any time).

[memoarfaa]

but if you welcome it, I will finish it

@memoarfaa, do you still plan to finish this?

Yes I will finsh it after one week

In its current state, I'm afraid that I only see an half complete pull request, that also fails to build on MinGW, and that is not something that I can integrate.

MinGW Build is fixed now.
Now we can use Visual Studio Code to Build and debug MinGW but my be but this in anothr br.

And I can definitely understand how completing the work might reveal to be a lot more time consuming than you anticipated

Sorry I was bussy last mounth but most work is done in my local build Dialogs, Controls, Menues , SystemMenus , NoneClient area is in dark mode now but still som small work to do .

@pbatard
Do you see MessageBox need to be darked also ?
Do you see MessageBox and System Menus need to be localized in the app and not depend on system local in Dark Mode?

2024-11-30_06-24-19_333.mp4

[pbatard]

Thanks for the update. Please take as long as you need to finish and clean up your code before finalizing the PR.

For the record, I would very much prefer if you merged all your changes in a single commit, rather than have to apply multiple commits - from git you can easily merge multiple commits into one, and, as long as you are working with a branch, GitHub is smart enough to detect and update the PR, even if you did originally submit it as separate commits. Oh and you should prefer to use rebase in git to update your changes to latest master, rather than pull the latest as a patch. If you need a good UI to help you do that, rather than rely on Visual Studio's, I recommend TortoiseGit which I what I use and which makes all git operations conveniently accessible through a couple of right clicks in the File Explorer. I'm also not sure why you got tons of whitespace changes in rufus.vcxproj (looks like you edited it in a text editor that beautified the XML), but you should be able to fix that by changing a property in the Rufus project in Visual Studio, save, and then changing it back, as VS will apply its own formatiing then. Having to look for changes in a sea of whitespaces makes them more difficult to review...

Do you see MessageBox need to be darked also ?

That's a strange question. Unless what you means is whether I think messageboxes need to be forced to use dark mode, in which case I'd say that, everything outside of the control of Rufus is to be left to the user/system to control, as the expectation is that if someone wants Dark Mode in Rufus, then they will also use Dark Mode for their system, so we should not have to care about going further than the direct Rufus UI.

The scenario where someone is using Rufus in Dark Mode from within Windows in Light Mode, and expects external system menus that are triggered by the app, but that do not actually depend from the app but from the system, to use Dark Mode, is one where I will tell the user "Well, you're trying to mix oranges and apples here, so it's your problem, not Rufus'".

Do you see MessageBox and System Menus need to be localized in the app and not depend on system local in Dark Mode?

Similar to above. I am NEVER going to do anything about system settings and system localization in Rufus. If someone is switching the locale in Rufus, but running on a system with a different Windows locale, then I expect them to understand both locales, and it makes no sense to divert a lot of time on something that will, at best, might be seen beneficial for about a handful of users... who will not really care about it.

So my answer to both is: No. The cost/benefit ratio is way to high to want to do anything about these things.