> The very bad move in this case, was hard-coding foreground colours, while simultaneously not hard-coding background colours.
Oh holy.
People act like dark themes, or theming is a relatively recent invention. But in fact, Windows 95 and even earlier were already entirely themeable, system-wide (well themeable is a bit of an exaggeration, you could modify the color scheme, but still...). But the quoted problem is exactly what was already happening back then to basically prevent you from ever deviating from the default colors too much. Sure, you could make the default gray background a little darker or brighter, but I remember I tried doing white text on black background, and after a couple days I encountered enough programs that at least in some places hard-coded black text but used the system default background color. What worked a little better was programs that forced both, some text editor forcing black on white, but that looked pretty jarring too, contrast-wise. Switched back to default colors and never bothered again to this day.
> Please, for the love of all that is good and decent in this world, the next time you force a visual change upon users, include a colour picker option to let the user override your choices, or, you know, respect the system theme.
Ironically, the article itself displays with hardcoded white-on-black text and neither 1. allows me to override its choices nor 2. respects my system theme. I have to "Disable Styles" in my browser to accomplish this.
I wish app and web developers would be more respectful of user's style preferences and their system theme. Some designer living 1000 miles away in Silicon Valley should not be able to simply dictate how my browser displays text or what color my application windows are.
I wish app and web developers would be more respectful of user's style preferences and their system theme. Some designer living 1000 miles away in Silicon Valley should not be able to simply dictate how my browser displays text or what color my application windows are.
Older web browsers used to let you override the colors for all websites as just a normal setting. I think I'm specifically remembering Netscape 3, but it's been a while. I used to override the colors, and disable images/js from like 96-99, and everything worked fine. I still miss that version of the web
"One of the fundamental features of CSS is that style sheets cascade; authors can attach a preferred style sheet, while the reader may have a personal style sheet to adjust for human or technological handicaps."
Safari still supports this. Preferences -> Advanced -> Style sheet. I use it to adjust things on some websites. As far as I know Chrome does not support it. Firefox probably supports it, but their preferences UI has always been terrible so I can’t figure out where it would be.
Firefox probably supports it, but their preferences UI has always been terrible so I can’t figure out where it would be.
I remember it being nicer about 20 years ago, I think it started getting gradually worse about the same time the release numbers started increasing like crazy.
Firefox still does: Settings -> General -> Colors. You can change the default color for text/background/links, and set it to always override the website's styling if you want.
What makes you feel like it doesn't allow you to override its styles? Unless it's doing some funny business with e.g. the shadow DOM, you can literally just add some CSS in your browser – the exact ease that this blog author was wishing for:
I'm not a web developer, but looking at "prefers-color-scheme," that seems like a good, but very tiny step in the right direction. I'd consider my system theme to be more than just binary "dark" vs. "light". What about font, text size, specific colors and appearance for content and UI controls, colors and fonts for link text, and so on. As a user, I shouldn't need to inject CSS, fart around with Greasemonkey scripts, or use the big hammer "Disable CSS," just to force my browser into respecting user preferences.
> I wish app and web developers would be more respectful of user's style preferences and their system theme.
The problem for app developers is that there are so many completely different implementations of theming in platforms. On Windows, you have the Win95 era legacy theming (color schemes, fonts and window framing), like five or six different UI frameworks that may or may not integrate with the legacy settings, and on top of that the entire DPI settings which many app developers don't bother to test. On Linux, you have the big players KDE and Gnome and a truckload of splintered smaller projects. On macOS and iOS, you don't have anything but dark mode. On Android, you have dark mode and fonts. On web, you don't have anything but dark mode (and I wonder if that's going to be taken away like a million other things that got exploited to fingerprint users!). Oh and you have Java frameworks that have the same limitation.
And depending which kind of framework you use, it may or may not well integrate with whatever implementation the OS provides.
I thought for most application frameworks, simply not doing anything is enough to make your application adopt the user's system preferences. You have to take deliberate action as a developer to override them.
I remember the early days of Windows 95, where for a brief, glorious moment in time, all your applications would look like proper Windows 95 applications, respecting your color scheme, text size and font face, highlight/disable behavior, tooltip/hover behavior and colors, everything. Everything you launched just looked like it fit in with the rest of the system. Then, I think one of the first (at least most prominent) egregious violators was WinAmp. You'd launch it and it just decided by itself what the title bar, status bar, min/max/close buttons, content, everything, should look like. And not just colors--they used bitmap graphics to entirely override what common controls looked like. It stuck out on your desktop like a sore thumb. Yuck! If you wanted to change its appearance, you had to use the application's own plugin or theming system since it just ignored the system.
Fast forward to today, and every developer just treats the application's entire visual surface as their own art project, basically ignoring the system preferences altogether. If you're lucky, they let you specify "dark" vs. "light" or even more rarely, let you go in and do minor tweaks using the app's own bespoke preference settings. But fallback to system colors? Fuggetaboutit!
Remember when web pages were text with a few images, with browser settings (font/size/color?) that let users style things to suit their own needs? Those were good days.
All self-respectable browsers have a "reader mode" that does what you want. You don't have to hack away at obscure options, it's one button click away.
Chrome is the browser that doesn't have a reader mode by default, due to the obvious conflict of interest.
This problem is a scourge of the Web. Literally half of all web sites set one of the two, assuming the default color scheme of black-on-white, resulting in beautiful unreadable blanks when the actual preset is white-on-black.
Back in 95 "SE", you could invert the colors on your own. My mom had this need to use a reddish background and black text that was a bit maddening. I would set the black text to white. It worked, for the most part.
I don't think there was a Windows 95 "Second Edition". Are you talking about the theming that was possible with the "Plus! pack" or something related to the OSR2 version of Windows 95?
The ability to set UI colours was a basic part of Windows 95 (or indeed 3.x before it). In 9x its just part of the Display control panel.
The Plus back added the Desktop Themes control panel and the various preset colour / wallpaper / sounds / icons combinations like Mystery and Inside Your Computer. This later became a standard part of Windows 98.
There is other, more sinister way to fuck it up, by just loading "wrong" color keys from the theme that still sorta look okay on white theme but are unreadable.
Basically, instead of reading description and using a color key from theme as designed, someone uses "default" (or whatever they have currently set on machine) color theme as essentially palette to paint their app with, disregarding original purpose and end up broken with some themes.
I think the fact that Windows is much less themable these days is a part of the problem. Back then, people actually used all kinds of weird themes, and that was a forcing function on the developers to stick to system colors. Win7 was the last version that supported it, though, and even then only if you used the Classic theme. Dark mode for Win32 apps wouldn't show up until Win10.
Eclipse with derivatives are incredibly bad at this.
Feels like every time I boot it I get different results depending on what order eclipse colors and theme colors is applied or something.
(no, I don't "use" eclipse but in the embedded world eclipse is still king (if you ask the vendors) so when I am on a new platform I often play around some in it before I managed to move off it entirely)
This is an example of a much bigger issue in the FOSS world.
In theory, FOSS puts the user in control - don't like one of the software author's choices? Just change it yourself!
In practice, this is another example for the long list of cases where it took someone with coding skills several hours to fix what's simply a style choice (what colour should the font be). Worse still, that effort was needed simply to get back to how it used to work by default, and it might need further effort to maintain every time the relevant code in the application is updated.
(It's not that this doesn't happen outside the FOSS world as well - see trying to get the title bar of the active window ONLY to take the theme color in Win11, for example - but to the extent that FOSS people claim one of their advantages over commercial software is end-user customizability, I hold them to a higher standard here.)
No, FOSS is not about putting the user in literal _control_, and that concept is misused a lot to look down on the idea. FOSS is about ensuring the user has the right to be in control whenever/however they want. Most users won't, ever, but the right is there, if they wanted and knew how to, and that is what FOSS accomplishes. Comment [1] happens to reply a similar thing.
In short, this whole issue with qBittorrent cannot be summarized better than this other comment [2]: developers who have no idea about design should not change design.
> A normal end user cannot do anything about this without significant effort.
This succinctly captures an important truth about computers (and especially mobile phones) over the past thirty years or so. Free software communities just don't, ironically, seem to have really had user empowerment as a core value since around the mid-90s or so.
> Free software communities just don't, ironically, seem to have really had user empowerment as a core value since around the mid-90s or so.
Of course they have. Empowerment is not simply teaching people how to code, it's first and foremost giving control to users. Allowing them to understand how things work, why it changed, participate in the community to ask questions, surface bugs, and discuss on features. Change tools because formats are standardized and documented. Just like farmers using open hardware tools are not expected to be able to repair everything, but to have the right to repair the way they want.
Why would I install the beta? The current version works fine. They don't need to change anything in the first place. And if they hadn't changed anything they wouldn't have had to "listen to the people" because there would've been nothing to listen about.
Seriously, begging developers to change or fix things doesn't count as "user empowerment", and neither does spending the 10,000 hours necessary to figure out the maze of interlocking horrible technologies required to try to fix it oneself. It's a developer full-employment theorem for sure: people's jobs depend on users not being able to address their own problems when it comes to getting computers to do what they need.
Unfortunatey the world is not ready for dark themes yet. I wish I could usw a dark theme but I find the current state unacceptable. Try using a dark theme and every now and then you will encounter a searchlight-bright white area hurting your eyes and contrasting everything uglyly. Some apps just have some white or almost-white panels alongside dark areas. Many websites only support white theme or require you configure them manually (it should be a single OS-level switch propagated to CSS by a browser).
This has to chhange for the dark theme idea to reach general usability.
Thehe already has been a time when you could just tweak all your colours and fonrs in the control panel and all the apps and all the websites would follow. But this was long ago.
By the way simple light/dark switch is not enough. I also want a low-detail theme to disable all the unnecessary visual noise and soothe my nervous system while the majority probably prefers fancy and shiny bells&whistles designs.
> Unfortunatey the world is not ready for dark themes yet.
A weird statement to make given that all the tools are in place; what you're describing is poor implementations. The world is ready, the implementations aren't up to par yet.
Personal pet peeve is Reddit, I use an alternative app for it that supports dark/light mode as every app should, but because Reddit is mainly used to post screenshots these days, they're often light themed screenshots. I wish the app(s) would apply a filter that applies a dark filter to screenshots.
There also certain areas of endeavour where a light-on-dark theme isn't appropriate. I remember using the superbly pretty Bryce theme on KDE1 back in the early 2000s - but quickly abandoning it because a lot of what I do is print-oriented. If you're designing for print then the "paper" is going to need to be white, so the UI elements had better have similar mean brightness and contrast levels to the representation of the page you're working on.
100% WYSIWYG is not necessary. I would prefer typesetting tools (incl. LibreOffice Writer) to use a dark theme during the work and printing black on white, letting you see a perferct WYSIWYG print preview briefly before printing.
"Designing for print" includes a lot of illustration, mixed media (text & image) DTP, photo editing, color management -- not just largely image-less typesetting. 100% WYSIWYG is absolutely necessary for most professional work.
In many (not all) cases it still can be a separate step. It's not something I do a lot but I did some and in some cases I would have been Okay this way. And perhaps that could be a healthier alternative to staring at a bright display for hours.
I don't have many hard and fast rules in my life, but one that I've learned through painful experience is this:
Never Update a BitTorrent Client
Version 1 of every bittorrent client is lightweight, fast, and does nothing besides torrent your bits. Version 4 is 400gb, takes 30 seconds to load, shows ads, installs a rootkit phoning home to the NSA and mines bitcoin in the background.
This is an inviolate for bittorrent clients. There never has and never will be an exception.
Yeah, here's a story about one of the incidents https://news.ycombinator.com/item?id=11234589. I believe there was another. But I guess even in spite of this, it's not fair to say it's crappy :). My bad!
As a non-native english speaker my internal voice stuttered while trying to read "through tough thorough thought", felt like a real life 4th wall break.
I think you just have a talent to finding shitty ones.
I used rTorrent for over a decade, only recently migrated to Transmission because I no longer cared for the text UI and client-server model fit what I did with it better
I feel really sorry for the developers. If I click on that issue, I get the impression that these don't seem to be moderated in any way, and the result is extensive bikeshedding.
The article itself is great though. I use qBittorrent and I run it in dark mode. I'm going to skip this version for now.
There is bikeshedding and there is developers with no concept of design redesigning UIs.
qBittorrent was already quite ugly, but this is just awful: https://github.com/qbittorrent/qBittorrent/issues/18078#issu... — why that bright blue on top of white? If you really want to make it blue, at least retain a decent contrast. And let's not even start with those icons... The shapes could work, albeit they are quite unrefined, but the garish colours do not convey any information nor show any artistic consistency.
(cue the "it's open-source, if you don't like it fork it, but dare not criticize us because it's rude" comment)
I am fine with people not being good at design, but the worst designers are convinced they are decent enough. It's like that law that eludes me right now, that people bad at something often overestimate their abilities and are blind to their shortcomings.
> (cue the "it's open-source, if you don't like it fork it, but dare not criticize us because it's rude" comment)
“If you don't like it, fork it” (or a little less polite “if you don't like it, feel free to fork off”!) is perfectly valid IMO. The second part should just be “don't criticize rudely”.
According to the issue, they tried to find one color that works for both light and dark mode. It ended up working for neither, but it was not random ;)
Close, but not quite. D-K is the law where someone who's really good at one thing (like writing software) thinks that this means they're super-smart and therefore must be an expert at everything else.
I'm afraid that is also not correct. Dunning-Kruger is defined as people with low ability in a domain overestimating their own ability in that domain – it does not require someone to be really good in another domain.
From my experience lurking in that repo, I found the development of Qbittorrent chaotic, and it has been like that for years.
They have no moderation in issues (hence 2.6k+ open issues);
Commiting frequency is (relatively) low for such a complex program;
And it also has lots of odd UX issues that has been solved on uTorrent at least 10 years ago. My pet peeve is that if you have "add .!qd to unfinished torrent files" option enabled, it somehow would prevent you to manually put completed files in and ask QB to re-check, a practice I often do to help seeding with files I already have (if you do so, it either totally ignore it when checking, or delete your completed file!)
I can't really tell why (lack of contributors, or just bad management), so I won't point fingers.
On the other hand, despite all the quirks and issues, the main functions work solid; and they seem to add/improve core features steadily. So I really have nothing to complain as a user. I just avoid updating to newest version in general.
The article doesn't mention how the new toolbar icons are also eyecancer, at least in dark mode. I had to switch to Text only buttons to avoid burning my eyes out from the bright red Remove icon on the dark gray background. So yeah, another reason for you to skip this version.
I just realised I've gradually replaced all of my GUI apps with terminal based ones... I use rtorrent, and as such cannot possibly have issues with UI colour because I define them "system wide" by setting the ANSI colours, which feels kinda like win95... does this make ANSI the most portable UI? because you do get it on all major platforms.
I didn't intentionally do this, but I do prefer terminal apps where they are comfortable and enjoy the consistency, minimalism, brutalism, legibility, scalability and control over colour and font choice.
It's a bit out there, but at some point the entire compositor could probably use AI like DALL-E to enforce a consistent theme regardless of how the app styles it. The next generation, the application won't even need to really spend a lot of resources rendering. Just a very low resource sketch + state (e.g. what text is where to make sure that the AI renders it correctly) of what it wants to draw and the AI will automatically render it at the correct resolution, anti aliased, consistent etc.
At the limit, this would degrade to an application only ever exposing an RPC-like interface that AIs hook into, some application-specific AI model describing how to represent the state / interact with the RPC, and the local AI will automatically generate the appropriate UI (command-line, TUI, GUI + themeing) as needed (e.g. text or speech input). This would be a game changer to how UIs are built.
However, I don't think the more advanced applications here are possible with today's generation of AI. It'll probably need some amount of AGI to problem-solve dynamically on the fly.
> at some point the entire compositor could probably use AI like DALL-E to enforce a consistent theme regardless of how the app styles it.
That seems eminently reasonable using today's technology (maybe with some acceleration). Certainly there's plenty of examples of style transference.
> The next generation, the application won't even need to really spend a lot of resources rendering. Just a very low resource sketch + state (e.g. what text is where to make sure that the AI renders it correctly) of what it wants to draw and the AI will automatically render it at the correct resolution, anti aliased, consistent etc.
Again, this doesn't seem out of the realm or need AGI since we have existence proofs of being able to take a low-value sketch and integrate it into a consistent theme. See https://ahrm.github.io/jekyll/update/2023/01/02/three-eyed-f... or Invoke's Stable Diffusion canvas https://www.youtube.com/watch?v=RwVGDGc6-3o&feature=youtu.be. Now sure, maybe applying it to a UI where you need things to be functional or there's things around text may pose challenges. Still, I don't know why this seems crazy, require AGI, nor do I see how ChatGPT applies.
I finally describe the most advanced application and literally say:
> However, I don't think the more advanced applications here are possible with today's generation of AI. It'll probably need some amount of AGI to problem-solve dynamically on the fly.
At what point do I claim that ChatGPT is AGI? In fact, I'm saying literally the opposite - we're nowhere close to AGI. It's possible we don't necessarily even need full AGI even for the most advanced use-case (i.e. automatically generating the UI), but certainly ChatGPT / DALL-E are NOT suitable for that, nor is it clear to me that they're in the right evolutionary ballpark (i.e. maybe you need AI that works totally different).
While we're at it, I'd like to give a shout-out to the UEFI devs who decided that in their shell, certain elements should be dark blue on a black background. That's lead to so much fun over the years when recovering machines.
It seems like this has been an issue with qBittorrent for a while? I'm using qBittorrent 4.4.5, when I switched to the Breeze Dark theme, all the text in the sidebar ended up being dark grey text on a dark grey background.
How does this happen? I get it when GTK apps are broken by themes, since GTK doesn't really officially support themes out of the box, and GTK themes are just default stylesheet hacks, not some solid theming API. But Qt has always had good official support for themes, and KDE has always exposed a dark theme in their settings app. Is KDE just not a target platform for qBittorrent?
The screenshot in the article is with torrents in seeding state, yours is with a torrent in downloading state. I think the problem is specific to the seeding state.
Oh holy.
People act like dark themes, or theming is a relatively recent invention. But in fact, Windows 95 and even earlier were already entirely themeable, system-wide (well themeable is a bit of an exaggeration, you could modify the color scheme, but still...). But the quoted problem is exactly what was already happening back then to basically prevent you from ever deviating from the default colors too much. Sure, you could make the default gray background a little darker or brighter, but I remember I tried doing white text on black background, and after a couple days I encountered enough programs that at least in some places hard-coded black text but used the system default background color. What worked a little better was programs that forced both, some text editor forcing black on white, but that looked pretty jarring too, contrast-wise. Switched back to default colors and never bothered again to this day.