Dark theme

[rakleed]



Checklist

• [x] I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• [x] I performed a search in the issue tracker for similar issues using keywords relevant to my problem, such as the error message I got from the log.
• [x] I clicked the 'Log' button or pressed Ctrl-L in Rufus, and copy/pasted the log into the line that says <FULL LOG> below.
• [x] The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• [ ] I ran a bad blocks check, by clicking Show advanced format options then Check device for bad blocks, and confirmed that my USB is not defective.
• [ ] I also tried one or more of the following:
  • [ ] Using a different USB drive.
  • [ ] Plugging the USB into a different port.
  • [ ] Running Rufus on a different computer.
• [ ] If using an image, I clicked on the (✓) button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.

Issue description

Please add a dark theme to the application. Because using your application at night or in dark rooms is very unpleasant because of the bright white background. Ideally, it would not be bad if the theme of the application matches the theme of the system.

Log

Rufus x86 v3.8.1580
Windows version: Windows 10 64-bit (Build 18363)
Syslinux versions: 4.07/2013-07-25, 6.03/2014-10-06
Grub versions: 0.4.6a, 2.04
System locale ID: 0x0409 (en-US)
Will use default UI locale 0x0409
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
Found USB 3.0 device 'SanDisk Extreme USB Device' (0781:5580)
1 device found
Disk type: FIXED, Disk size: 32 GB, Sector size: 512 bytes
Cylinders: 3814, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 2
Disk GUID: {030D783E-D755-4F13-B0DE-DC4CD198923F}
Max parts: 128, Start Offset: 17408, Usable = 31376672768 bytes
Partition 1:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'Main Data Partition'
  ID: {DE2B131C-7262-4342-AAB4-31DCCE44F22E}
  Size: 29.2 GB (31374572544 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000000
Partition 2 (UEFI:NTFS):
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'UEFI:NTFS'
  ID: {A2D082BE-05CD-49F3-9B5C-866508AAF678}
  Size: 512 KB (524288 bytes)
  Start Sector: 61280510, Attributes: 0x0000000000000000

[pbatard]

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

[pbatard]

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.

[wefalltomorrow]

😃

[pbatard]

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...

[wefalltomorrow]

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.

[freakshow999]

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?

[wefalltomorrow]

@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

[AnuthaDev]

This might be useful: https://github.com/microsoft/ProjectReunion/issues/41#issue-622186032

[pbatard]

@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.

[MarcAnt01]

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

[pbatard]

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.

[MarcAnt01]

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

[sukhchainn]

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.

[the-j0k3r]

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.

[regdfvtr]

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!!!

[MarcAnt01]

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

[AnuthaDev]

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

[AnuthaDev]

https://github.com/notepad-plus-plus/notepad-plus-plus/commit/5a3bf49c86acca8863a1be2fb12038f18c54594a

[pbatard]

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...

[ysc3839]

@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?

[pbatard]

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.

[MarcAnt01]

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

[AnuthaDev]

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

[pbatard]

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... 😄

[ysc3839]

@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.

[MarcAnt01]

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

[pbatard]

@ysc3839, I'll take a look, thanks!

[ysc3839]

@pbatard You can use https://github.com/nptr/msstyleEditor to see how those themes looks like, their name starts with DarkMode_. And that's why you can't get the actual colour for button faces, because they are a whole image.

[yodaluca23]

So umm... just an idea... I don't know (I mean I think it would probably be easier to program...?) but couldn't you just make it invert the light mode Rufus when the system is in dark mode...? As in just put a High contrast filter over the Rufus interface... It should work fairly well as Rufus mostly just has blacks and whites anyways.

[rasyidf]

I mean I think it would probably be easier to program...?

I guess it isn't as easy as it seems with win32. 😢, if it's webapp then maybe yes.

[rasyidf]

Moving to newer tech, also seem easier than doing some tricks.	Dark Mode	Light Mode

I recreated Rufus UI with WinUI, and it's beautiful. but there's tradeoff, it's windows 10+ only. AFAIK.

[MarcAnt01]

@rasyidf this also makes the app look really modern (also how is 10+ only an issue here? W7 is eol and some years have passed, people shouldn't be using it on the first place and if they need rufus to update to a newer version they can use old versions, no need to lock other users)

[rasyidf]

well then, we just have to wait for Windows App SDK to mature enough. AFAIK, the C++ WinUI3 is packaged, and the Unpackaged version is still not ready.

[MarcAnt01]

Honestly I don't like unpackaged apps, but maybe apps like Rufus are cases where it makes sense, since users might not want to have it installed since it's used for one-time operations

[yodaluca23]

I recreated Rufus UI with WinUI, and it's beautiful. but there's tradeoff, it's windows 10+ only. AFAIK.

This is absolutely gorgeous can we not just have this version on say...? The Microsoft store then have the other version that works on all Windows OSs somewhere else (The official site, Github, etc)? That way any windows 10+ user (Around 1.4 Billion users) can 1. get it easily from the MS store and, 2. benefit from the new UI with dark mode 3. Unlock new features available to improve Rufus within Win 10+ Of course both versions would be on this Github, or a different one for the new UI one but keep both somewhere on Github

[pbatard]

That way any windows 10+ user (Around 1.4 Billion users) can 1. get it easily from the MS store

https://www.microsoft.com/en-us/p/rufus/9pc3h3v7q9ch

2. benefit from the new UI with dark mode

Again, repeating what I already said, I am planning to use XAML/WinUI/XAML islands, when it's stable enough and, much more importantly, WHEN I HAVE ENOUGH TIME IN FRONT OF ME (which isn't the case right now) to split Rufus into a commandline + UI version, that will have an "ooh, shiny!!" WinUI interface similar to the one proposed above.

The problem is that creating a mockup takes 5 minutes. Creating a working application where UI and core as dissociated, as well as solving the issues that people who create a mockup are not considering (accessibility, translation framework for the many languages Rufus is translated into, the mess that is commonly associated with using brand new technology that has still not been entirely finalized by its maker, and the myriad of other things that people are quick to brush under the table as "non-issues" when they most certainly are going to be a massive development time sink), takes 5 months.

So, the reason why you guys are not seeing any progress on the dark mode front, is because:

1. I am waiting for enough people to have moved to Windows 10+ where WinUI/XAML islands can be used.
2. I am waiting for XAML Islands to become used by enough developers so that I don't have to waste time blazing a trail of discovery for it (it's nice when you find answers to questions about a technology on stackoverlow).
3. I'm am waiting for my schedule to allow me to spend months on end on this kind of UI redesign.

3. Unlock new features available to improve Rufus within Win 10+

We really don't have to switch to WinUI/Windows Store to do any of that. Whenever a new version of Windows introduces something we can use, we do use it, even if it's incompatible with older platforms. This is why for instance Windows To Go was introduced at a time where we still supported Windows 7, but was flagged as incompatible with that platform on account that it relied on features that are only present in Windows 8+. So we've never ever been bothered to wait for people to migrate, to take benefits of new features that we could use.

Also, and to dampen this very wrong idea that everything's peachy when an app is provided from the Windows Store, please bear in mind that the Windows Store places very problematic restrictions on what an app can do. For instance, the Store version of Rufus cannot use the more modern way of formatting and dealing with partitions provided by the Windows VDS infrastructure, because Microsoft has decided that Store apps could not use VDS. This is actually quite problematic, because I wanted to switch to VDS as default, but can't do that. And from time to time, I have to guide people away from using the Store version of Rufus, on account that they need VDS to complete their task.

All this to say: be very mindful of the rosy picture you are trying to paint just because you want an "ooh, shiny!" new interface for Rufus, and the amount of work that it will actually take to get there.

There really are only so many ways I can re-state that, you will get the nice WinUI/XAML interface you want, where dark mode will be automatically handled, but it will take A LOT more time than you expect to get there. And I'll bring the point further back home by stating very explicitly: This will not happen before at least another year, at best, or, probably more realistically, two, because, between improving the app just so that people can tell "it looks nice" and improving the app so that it does a better job at creating bootable media and corrolary work, I have no doubt that you can easily tell which one I'm gonna pick.

These things do take time. And trying to make it look as if they don't, or are/should be easy to accomplish, is actually doing a disservice to everyone.

[the-j0k3r]

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

[Silther]

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).

[RokeJulianLockhart]

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

[johngagefaulkner]

@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.

[pbatard]

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...

[blattersturm]

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

[MarcAnt01]

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?

[pbatard]

@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.

[riverar]

@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.)

[pbatard]

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... :wink:

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...

[ysc3839]

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.

[pbatard]

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...

[YourOrdinaryCat]

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.

[rasyidf]

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