I'm going to defer that one.

For one thing I'm not going to add a dark theme, or themes in general, because we're not dealing with a media player application here, so the ability to use custom themes is hardly something I want to spend time on when it is a limited resource.

On the other hand, yeah, it would be better if Rufus used the same default colors as the current Windows theme, but we're not using WPF, UWP or whatever the latest flavour of the day Microsoft decided to go with for their n^th attempt at revamping GDI and try to coerce developers away from using perfectly functional C interfaces, so this is going to need some work, especially as we tried to future-proof our color picking for just that case, by using GetSysColor(), and Microsoft, for NO FRIGGING GOOD REASON, decided that GetSysColor() cannot be used to pick Dark Theme colours...

I'm also seeing worrying reports (same link as above) such as:

In the case of classic apps dark mode is problematic because basic Windows controls (buttons, labels, edit fields) do not support it.

Well, basic Windows controls are what Rufus uses, which means that, as opposed to what many people seem to think, adding Dark Theme support to Rufus is likely to require a lot of work for a feature that, when all things are considered, is a minor inconvenience at best (sorry, but your eyes are not going to start bleeding just because an app doesn't have a Dark Theme). As such, I'm going to defer this for now, which means it'll probably be years before I look at it, and, because Microsoft seems adamant about making the life of old-school UI developers miserable, with no guarantee whatsoever that it's ever going to be implemented.

→ Deferred

Oh, and as always, if someone is really annoyed by this and can produce a Pull Requests that adds the feature (but without making UI handling a lot messier than it already is), I'll be happy to apply it.

😃

I've had some of that for a while too (haven't bothered with the dropdown or status bar yet, since as I stated this isn't a high priority and I've had more important things to deal with):

I mean, why else do you think I bothered with this recently?

Hopefully, if you are trying your hand at it rather than just publishing a quick screenshot, you are realizing that there's a lot more to doing dark mode properly than people realize. For one thing, if you want to have colours for the progress bar that are consistent with the user's theme, rather than force ones you pick yourself, you probably found that Microsoft's GetImmersiveColorXXX() APIs are mysteriously missing some important values, such as the border for buttons and so on, which would really come handy...

So, again, for all the impatient folks who may be tempted to think that this is a 5 mins job, adding proper dark mode support is not as simple as a dropped screenshot may lead you to think. And also, this is a low priority issue, which means it's unlikely to happen fast, especially as I don't want to go for quick and dirty fix that would both be problematic to maintain and ignore Windows' allegedly officially way of picking theme colours...

I didn't change anything within Rufus, I have a 3rd party theme applied to Windows which trickles down to other applications such as Rufus, qBittorrent, Everything, etc.

I didn't change anything within Rufus, I have a 3rd party theme applied to Windows which trickles down to other applications such as Rufus, qBittorrent, Everything, etc.

Care to share the name of the program/theme?

@freakshow999 commented on 11 May 2020, 18:20 GMT+10:

I didn't change anything within Rufus, I have a 3rd party theme applied to Windows which trickles down to other applications such as Rufus, qBittorrent, Everything, etc.

Care to share the name of the program/theme?

Program to patch Windows to allow 3rd party themes: https://www.syssel.net/hoefs/software_uxtheme.php?lang=en

Theme I'm using: https://www.deviantart.com/kdr3w/art/Dev-825722799

This might be useful: microsoft/WindowsAppSDK#41 (comment)

@AnuthaDev, that's what I'm using for the screenshot I posted above, but thanks.

Again, I am working on adding Dark Mode, but as you should understand, it's just not that high a priority.

I agree dark mode is needed, but a theme manager is not necessary. I think following system choice is the best option out there

I think following system choice is the best option out there

That's the plan. But, again, it's very low priority compared to other stuff. And it's not as simple to add as people think it is.

Yeah, just saying that the idea of a theme manager is totally useless

I would like to help in the making of dark mode, the dark mode rises.
I'm looking for open source project that need help, please let me know where to start.

I would like to suggest that in this dark mode design, that colors (assignments) are sourced from a file in human readable format, that in turn could be loaded as internal/external resource to Rufus.

This way for the tweaker in everyone can replace the assigned default colors with their own or create preset theme colors that can be shared with other users.

A dark mode is not needed. Seriously, what is the point of dark mode of an app like this. It's like installing Windows Vista on Windows 10! Rufus is great but a dark mode is DEFINITL NOT NEEDED!!!

A dark mode is not needed. Seriously, what is the point of dark mode of an app like this. It's like installing Windows Vista on Windows 10! Rufus is great but a dark mode is DEFINITL NOT NEEDED!!!

And your point being? Seriously, if some people ask for a feature, just accept that even if you don't. Comments like yours just sound like flame to me

Slightly unrelated, but if someone wants to implement acrylic along with the dark theme, this should be helpful:

https://notes.yvt.jp/Desktop-Apps/Enabling-Backdrop-Blur

notepad-plus-plus/notepad-plus-plus@5a3bf49

Yes, it must indeed be real nice when someone, who isn't the main developer, first announces that they are planning to work on Dark Mode for a project (so that the main dev can chime in and provide guidance if needed) and then, after a few weeks work, come back with a PR that the dev can apply... 😄

I'm afraid the code that N++ uses for Dark Mode is not that helpful for Rufus. And I don't really need it anyway, since I've been looking at what ProcessHacker does in that respect, which is more useful to me.

IIRC, the biggest issue I had, at the time I stopped the Dark Mode effort, was that there doesn't appear to exist a win32 API that allows you to get the actual colour for button faces, button borders, etc., when the default Windows dark mode theme (such as the one used by Explorer) is in effect. That's the reason why I bothered with this as one would have thought that, when listing all the Immersive theme colours, which is a very long list, Microsoft would have all the UI elements' individual component colours in there (Narrator: "They don't"). And at this stage, knowing that there is a UI redesign of Rufus planned down the line, that should hopefully use XAML and WinUI, it's difficult to see spending more time on pure win32 dark mode, when the chances are that it will come without having to do anything then...

@pbatard

was that there doesn't appear to exist a win32 API that allows you to get the actual colour for button faces, button borders, etc.

Can you explain why this is the biggest issue?

Because if you don't use the same dark theme as the system, people complain that what you are using doesn't match what they expect. And I've actually already seen people have some reservations about N++'s dark theme (though I'm not sure if that is linked to that).

The major problem when dealing with stuff as subjective as a dark theme is that, if you make any decision that deviates from what Microsoft uses, people will complain that you should have picked something different, that they like better. But by following Microsoft's theme exactly, I can avoid all the annoyances that come with individual accounting for taste.

@pbatard so are you planning on rewriting Rufus using WinUI?

@pbatard Can't we go all hacky and hardcode the colors used by explorer🤔🤔

so are you planning on rewriting Rufus using WinUI?

At this stage, yes, that is the plan. Knowing that plans can change, especially after I start looking at WinUI more closely. But going through a WinUI redesign could solve both the issues of dark mode and console Rufus version.

Can't we go all hacky and hardcode the colors used by explorer

They are not fixed. And therein lies the issue. They follow the colour theme set by the user.

Anyway, just like N++, I'll take a PR if you're willing to work on one... 😄

@pbatard
But Microsoft doesn't use Immersive Color for Win32 controls dark mode. They just use a dark theme to render control.
You can see my project https://github.com/ysc3839/win32-darkmode for example.

Then, I definitely understand your point. It's better not to spend further time on some work that could be useless for the future👍🏻

I'm with @pbatard

When time and energy being two of the constants that we have limited amounts of for any given task and when expended, we do not get it back under any scenario. One must fully understand that expending time and energy on any given task , must be prioritized by order of the greatest amount of benefit to the largest amount of people vs time and energy expended on task, and not the other way around.

I appreciate the hell out of Rufus and the quality of the end result, and while I personally prefer dark anything, I am willing to wait with minimum fuss. Ive already made my suggestion above.

Take care

With the release of Windows 11, one can be really glad that no attempt was made to switch to Acrylic, UWP or WinUI 2.
Hopefully Microsoft will not change the entire design again with Windows 12 (except for their own Windows Vista legacy components).

@xIUPITERx, I, for one, would be over the moon if Rufus were to use WinUI.

@pbatard Considering that using WinAppSDK & WinUI 3 decouples the UI from the code, would it be worth my time to make an initial design and share the XAML here? I'm asking because I have the time, ability, and willingness to create a (very simple) initial design so that, instead of having to write all the boilerplate and learn XAML at the same time, your work could begin by simply redirecting the event handlers of the controls to your CPP methods. However, if you wouldn't use it or it's simply not something you're interested in, then I won't waste my time. Let me know, thanks.

using WinAppSDK & WinUI 3 decouples the UI from the code

That's not exactly how I'm planning to do it. For varied reasons (one of which being that Rufus is not designed to come with an installer, but will remain a single executable... which will probably transparently extract and run another executable at runtime behind the scenes), I am planning to use XAML Islands from within a non WinAppSDK.

Which means that, if you want to help, you will need to make your XAML somehow work after we have instantiated the grid in a project like this (which is a simple TEST of XAML Islands and does NOT have any implied bearing on how we are going to effectively implement a WinUI version of Rufus).

Well, as far as I (currently) know, unless you write your own parser, I'm not too sure how you can actually use a formal standard XAML text declaration to instantiate control elements, and it does look to me like Microsoft does expect the instantiation to happen through explicit code declaration.

So, I wouldn't mind the help if you can figure out how to pick up an XAML text definition after or when the XAML Islands grid has been/is being created, and make all the UI elements get instantiated nicely (along with usable Windows::UI::Xaml::Controls bindings in the code) without having to go through a lot of code boilerplate.

If not, then I'm afraid that I don't think I'll have much use for any boilerplate XAML text declaration, as I will have to come up with my own "declaration → code instantiation" solution to keep the XAML Islands limited framework happy, and chances are that I am not going to write a formal XAML parser to accomplish that.

Then again, I have not had the time to sink much time into XAML Islands yet and when I did (last year, which is when I crafted that xisle sample project) the documentation was obviously severely lacking, so maybe, for once, Microsoft did not provide only a half-assed solution for developers who need to deviate from their "If you want to use XAML, you will package your application with an installer, and in the specific restrictive way that we have decided", and there is actually a simple way, when using XAML Islands, to go from an XAML text definition to WinUI controls that are accessible and usable in C++ code...

Well, as far as I (currently) know, unless you write your own parser, I'm not too sure how you can actually use a formal standard XAML text declaration to instantiate control elements, and it does look to me like Microsoft does expect the instantiation to happen through explicit code declaration.

We use winrt::Windows::UI::Xaml::Markup::XamlReader::Load (MSDN docs) for this, apparently:

https://github.com/citizenfx/fivem/blob/843247aae475eb586950a706015e89033e01b3f4/code/client/launcher/UpdaterUI.cpp#L1378

That's not exactly how I'm planning to do it. For varied reasons (one of which being that Rufus is not designed to come with an installer, but will remain a single executable... which will probably transparently extract and run another executable at runtime behind the scenes), I am planning to use XAML Islands from within a non WinAppSDK.

@pbatard I do not understand this point, WASDK/WinUI 3 supports running unpackaged, so what exactly is the issue here?

@MarcAnt01

WASDK/WinUI 3 supports running unpackaged

But require dependencies to be installed, and that is the issue. Per https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/downloads (runtime downloads):

Apps packaged with external location, and unpackaged apps, that use the Windows App SDK can use the standalone .exe runtime installer or MSIX packages to deploy the Windows App SDK package dependencies with them.

So (and that was the case when I tested in 2022, but maybe that has changed, though I doubt it has) you can't just pick a WASDK/WinUI 3 unpackaged executable, put it on a vanilla Windows 10 machine (with a build high enough to run WinUI) and expect it to run. Instead, you have to rely on the user to either have installed the SDK runtime dependencies or chain the SDK runtime installer as part of your executable:

Developers of packaged with external location and unpackaged apps are responsible for deploying required Windows App SDK runtime packages to their end users. This can be done either by running the installer or by installing the MSIX packages directly.

I can't see myself embedding the MSIX installer in the Rufus executable and asking folks to go through a costly install, whereas, as opposed to this, XAML Islands do appear to not require any dependencies to be installed to run.

And that is why WASDK/WinUI 3 is not a solution we can currently go with...

@blattersturm

Thanks a lot! I will test this (when I have a chance — again I have to stress out that I currently don't have the scope to work on this because there are more pressing Rufus related matters that I need to address first), but this looks like what I had been looking for, and it should alleviate the need to go through a lot of explicit code boilerplate just to duplicate what a plain text XAML definition is meant to avoid.

@pbatard Your assessments are spot on. I'd like to note, however, that the older baked in WinRT XAML you discussed potentially using (for islands v1) is effectively dead in maintenence mode. Building anything new on top of WinRT XAML at this late stage is probably a bad idea. Microsoft itself is slowly transitioning its apps and surfaces to WinUI 3 XAML and the WinUI 3 team is solely focused this year on making those internal/partner apps work. But with the very valid caveats you listed earlier, I understand this leaves no ideal way forward. Welcome to the club! (I'm stuck in the same boat.)

the older baked in WinRT XAML you discussed potentially using (for islands v1) is effectively dead in maintenence mode.

Just like plain old GDI, which is what Rufus currently uses, has been dead/in maintenance mode even before I chose it as the UI framework I would go with in Rufus... 😉

The thing about Microsoft is that they don't retire working UI frameworks... ever. So maintenance mode is fine when you don't actually care about the bells and whistles of whatever new rainbow coloured controls Microsoft decided to add in WinUI 2+ in order to woo youtube influencers who want to try their hand at creating a Windows app using ChatGPT...

Even if it was like Windows To Go, that was officially "retired" by Microsoft and that everyone has been giving for dead for years, but which continues to work just fine with the latest Windows 11 images because it is based on a such a fundamental feature of the Windows imaging and booting system that Microsoft doesn't really have any other choice but to keep making sure that it works, I wouldn't be that worried. But, regardless of how they want to flag it as deprecated, it has to be even more critical than that to Microsoft, because, even more than Windows To Go, this is user front-facing technology, that they wouldn't be able to remove without getting lots of calls from irate corporate customers complaining that whatever application they developed 10 years ago using WinRT XAML no longer works, which, ultimately, is what Microsoft primarily cares about, as evidenced by their choice to, for instance, of making Windows 11 lie to application when it reports its OS version to be Windows 10, or not reporting the newer USB 3.2 speeds...

Building anything new on top of WinRT XAML at this late stage is probably a bad idea.

I guess I'll take that chance.

After all, it won't be the first time I will be ignoring Microsoft's UI framework du jour (such as MFC, WPF and so on) to go for the pragmatic solution, that Microsoft will never want to acknowledge as the actual better option, but which is the de-facto one. Besides, considering how Microsoft can't ever stick to one UI framework for more than 10 years, I pretty much expect all of WinUI to be declared in maintenance mode in 7 to 15 years time (when Microsoft decides that they can't make WinUI work well enough with Rust or whatever, and push developers to use yet another UI framework to fix the poor design choices they made with the last one...), as has happened with MFC and WPF, so that using WinUI 1.x, 3.x or y.z won't make much of a difference...

But yeah, part of the reason why I am not rushing head first into WinUI and XAML Islands is that I'm still waiting to see how things will play out, and what Microsoft ultimately decides to do with the big issue of trying to bring legacy Windows applications into a more modern UI framework... Maybe if I wait long enough, Microsoft will actually introduce a solution that offers a real upgrade path for legacy GDI apps, and not one that comes with such awful compromises that Microsoft has no choice but to supersede it with something else...

Well, as far as I (currently) know, unless you write your own parser, I'm not too sure how you can actually use a formal standard XAML text declaration to instantiate control elements, and it does look to me like Microsoft does expect the instantiation to happen through explicit code declaration.

@pbatard @blattersturm
It's possible to make a single-exe xaml island app. Please see my project https://github.com/ysc3839/SingleExeXamlIsland It's done by hooking system function.

It's possible to make a single-exe xaml island app

Well, yeah. That's what I did in https://github.com/pbatard/xisle, which I referenced above.

That's was never really a contention point, except for the matter of being able to potentially use what the person who proposed to help with providing a UI mockup may provide. In short, there was never a major issue about loading an XAML file to instantiate the UI because creating XAML elements one way or another is peanuts, whether we can do it from plaintext XAML or not, and the main issue is with ensuing that whatever we do for the UI will work when a user on a freshly installed copy of Windows 10 gets Rufus as a single executable...

The solution from @ysc3839 would be best I think, if using the WinUI 2 styles is in the cards. I don't think bringing in the entirety of WinUI 2 (so the Microsoft.UI.Xaml.dll) would be actually possible with the single exe requirement - not on Windows 10 at least -, and as far as I know, it's not possible to create custom control templates from code without XamlReader, which is unfortunate when just the default button style + template from WinUI 2 is 100+ lines of XAML... and it still doesn't include everything, because it relies on the common theme resources. Rinse and repeat for every control you want to style - which to be fair, wouldn't be that much, because Rufus has a fairly simple UI that doesn't need many controls.

I think it's all worth considering if a redesign using XAML is under consideration - it would be a pretty large effort anyways, so having it use the newer styles would be a nice cherry on top. On the other hand, even if waiting for WASDK improvements could take a long time, I guess this isn't at a high enough priority for that to matter - Rufus already looks pretty nice after all.

I've tried making rufus UI using winui3 with single-file app, unpackaged app, without any code behind logic, and guess what?
The size is surprisingly big with 60mb executables, (Ms.Ui.Xaml.dll packaged inside)

you can build yourself here https://github.com/rasyidf/rufus-next

That's nice and I truly applaud your effort.

However, the current xisle exploratory project, which is what I'm planning to base the next Rufus UI on, and that is also based on an XAML UI, generates an executable that's only about 250 KB in size (and shouldn't grow that much in side from adding more UI elements), does not need to rely on separate DLLs or an installer and also does not require switching the interface to a different language (as long as you consider that C++ and C are similar languages though that last one is a minor point as I don't specially mind C# since I already have some elements for Rufus in that language anyway).

So, yeah, I'm afraid I see no reason to deviate from my original plan, which is to use XAML Island in a C/C++ app, as your project demonstrates that there doesn't seem to be much benefit to switching to full blown WinUI app...

Thanks for the kudos! 😍
my app's more of an experiment, so no worries.
I just learned that we could make smaller apps using C++, i should learn from xisle

It's been 5 years since this issue was created and we still don't have a dark theme!? Does the developer like to work at night with the light Windows theme or what? Or we have to keep using third party themes?

By the way, I warn you in advance that if you don't apply the dark theme to Rufus before the end of this year I will move to Ventoy.

By the way, I warn you in advance that if you don't apply the dark theme to Rufus before the end of this year I will move to Ventoy.

Ventoy and Rufus are not competitors... Their two very different tools, for too very different use cases..

It's been 5 years since this issue was created and we still don't have a dark theme!?

And it's been 4 years since I explained that, after exploring various options, I decided that I would add Dark Mode when I redesign Rufus to be WinUI based (which is a long term and relatively low priority effort). And just to be absolutely crystal clear, let me put this in black and white once again: While I am planning to add Dark Mode support, eventually, it will NEVER EVER become a top priority, no matter how much a small minority wants to whine about it, or are under the impression that the other stuff, that I am actually devoting my time to in the meantime, can't be that much more important or much more helpful to end users...

I'll also be honest: I couldn't care less if not having Dark Mode support is such a deal breaker that you and some other people move to a different application. More power to you! What I do care about is people having choice when it comes to creating bootable drives or other tasks, which is actually the reason I created Rufus in the first place, and I am therefore quite pleased that Ventoy and other utilities do exist (even more so as Ventoy has allowed to squelch the stream of "Multiboot in Rufus WHEN?!?" I got from a small number of rather entitled users). The last thing I'd want would be for Rufus to aim at becoming some kind of monopoly when it comes to boot media creation, and/or its developer(s) to try to retain users at any cost. If Rufus dwindles in popularity (and it's not due to entities like Microsoft or Linux distros restricting the ability to create OS installation media to their specific utilities), it'll mean that something else, that users have found to be better suited for their needs, has come along, and that's 100% fine with me, because that's how software competition should work. So, while I'm sure there are some commercial companies that think in these terms, and by extension, some software users who are under the impression that user retention is something that developers should focus on, this is actually not a healthy way of conducting software development. By all means, developers should never ever have to put user retention at the top of their priority list, but instead develop software that, on its own merit, will naturally attract users (and no, those are not the same thing).

Which brings us nicely to the conclusion I'd like to put, to everybody who is frustrated by the lack of speedy development on the Dark Mode front: Considering that, despite the lack of Dark Mode support, and the availability of innovative "competitors" like Ventoy, users do not seem to be moving away from Rufus en masse, it's pretty clear that Dark Mode support is not a dealbreaker and can therefore continue to be delayed as a low priority item.

I don't actually think Ventoy has a dark mode at all.

I only found some custom theme made by a non-Ventoy dev so it's clear they don't think dark theme is very important either

Right, and Windows itself doesn't have complete dark mode support. Not sure adopting an incomplete OS feature is worth anyone's time. But that's just me.

I don't actually think Ventoy has a dark mode at all.

The Ventoy themeing engine is very powerful. Take a look at Medicat. They have a custom theme that does a whole bunch of cool stuff.

I don't actually think Ventoy has a dark mode at all.

I only found some custom theme made by a non-Ventoy dev so it's clear they don't think dark theme is very important either

Ventoy has support for themes through grub2 themes https://www.ventoy.net/en/plugin_theme.html, and here is an example to use it in dark theme https://github.com/jfcherng/Ventoy-theme-poly-dark, and those are very pretty https://github.com/odiegoduarte/ventoy-themes

High quality design for rufus

This is a demo of UI design for Rufus. If the developer of the program likes the design, then write to me by email (it's in my profile) and I will give you the design sources that I have in Figma. I don't need anything in return. This is free from me for this program. And yes, I am not a professional designer, but you could say a junior.

Nice work @dunottrue You can make a dark theme version, so the dev doesn't like the dark theme?

@dunottrue, I think your design looks great, and, if it's okay with you, I may indeed want to use it as inspiration when I redesign the UI (which again is not going to happen for some time, because there are simply way too many other features that take priority).

For a non-professional designer (as you qualify yourself) this looks very elegant and intuitive to me, so thanks a lot for being willing to submit this for future use. For what is worth, the 2.x → 3.x UI Fluent-like redesign of Rufus was also submitted out of the blue by a third party, and was very happy to use it as a base, so it wouldn't be the first time I'd use an external UI design in Rufus.

I was however unable to find your e-mail on your profile (I think the e-mail address does appear for the owner of the profile, but not to anybody else). So if you could e-mail me the design sources to [email protected], I would appreciate it.

@pbatard, Okay )
I sent you the design file by email. If you have any questions for me, ask. I didn't implement the dark theme in the design, but everything is simple here... you need to repaint everything that is white in dark, you can go for a slightly blue shade.
and make everything that was dark (fonts) white. To do this, you only need to change 2 colors.

@dunottrue I don't mean to bash your work here, but...I can't help but notice that the contrast is quite poor, between some elements in your mockups. Might I suggest making your shades of gray a tad more prominent, for starters?

I really wonder why it makes people angry that there is still no dark mode. It is a small window, its not even white, but grey and it absolutely doesn't burn into eyes. What, people just run the program and staring on it for hours?

Rufus is insane piece of software with briliant, simple UI/UX.

@dunottrue your design might looks nice on first sight, but it is made with idea what I call - "use more to show less". Microsoft came with this with Win10. You introduced a lot of tabs, you need to make more clicks to change settings, huge controls which doesn't make sense to be so big. Problem with designers last 10+ years is that they want to introduce something new (everywhere) but in reality it is worse then existing design. Just look on Win11, where you need to do more clicks to do same thing compared to Win10.