Dark theme #1453
Comments
|
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 nth 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 I'm also seeing worrying reports (same link as above) such as:
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 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. |
Care to share the name of the program/theme? |
|
@freakshow999 commented on 11 May 2020, 18:20 GMT+10:
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 |
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 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!!! |
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: |
|
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... |
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🤔🤔 |
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.
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 |
|
Then, I definitely understand your point. It's better not to spend further time on some work that could be useless for the future👍🏻 |
https://www.microsoft.com/en-us/p/rufus/9pc3h3v7q9ch
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. So, the reason why you guys are not seeing any progress on the dark mode front, is because:
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. |
|
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. |
|
@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. |
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 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... |
We use |
@pbatard I do not understand this point, WASDK/WinUI 3 supports running unpackaged, so what exactly is the issue here? |
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):
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:
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... 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 |
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...
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... |
@pbatard @blattersturm |
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 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? 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! 😍 |
|
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. |
Ventoy and Rufus are not competitors... Their two very different tools, for too very different use cases.. |
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. |
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. |
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 ) |
|
@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? |
and others
Checklist
<FULL LOG>below.Rufus version: x.y.z- I have NOT removed any part of it.Additionally (if applicable):
(✓)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
The text was updated successfully, but these errors were encountered: