Hyperlink difficult to see with dark theme
pablos-here opened this issue · 19 comments
Hi,
When running QDirStat with a Dark Theme, hyperlinks are difficult to see - see the screenshot below.
One idea is to add to the color scheming editor the ability to change object colors:
- Hyperlinks
- Path names
- etc.
Screenshot
Well, yes; that's the way your desktop's dark theme does it. Please take that up with the developers of that theme. All QDirStat does is use it.
I am personally not at all a fan of dark themes because those problems are all over the place. I find those dark themes barely usable.
Well, yes; that's the way your desktop's dark theme does it.
Hi,
Below is a code snippet where the link color is hard coded - see message.ui.
Any chance you would reconsider exposing it for people with visual disabilities who have to use dark themes (like myself)?
Thx!
Line 148 in 07e7a45
I have an idea! :)
How about I work on a message.ui that is more dark theme friendly. Once I have something that works in my environment, you can add the functionality for different themes. The default theme would be the current one. People can PR different themes.
What do you think?
This is what Qt Designer (the interface designer) generates when you insert a hyperlink in a QLabel. I guess they are using the same values that they use for a QRichText style sheet. It's what people normally expect a hyperlink to look like in a normal (web-browser like) environment where there is typically a light-colored background.
There is a reason why I chose to use the interface designer for this project: To avoid a ton of boilerplate code for mundane stuff. I really don't want to overengineer this with a lot of code that just determines the font color of a hyperlink (that is used very infrequently to begin with), adding config parameters, duplicating them for both the normal case (a light widget theme) and the exceptional case (a very dark widget theme) with a threshold determining which one to use etc. etc.; that is leading nowhere.
Anybody who has visual impairments should know better than to use a dark widget theme: It's the norm, not the exception, that there is poor contrast everywhere.
There is a reason why after the bad old MS-DOS days in the 1980s where a black CRT monitor with green, amber or later white font color, all systems rapidly changed to a white background with black font color because it's much better to read: Atari with GEM, Amiga, MS Windows, even Sun and SGI workstations.
Using a dark widget theme in the 21st century is not done for necessity or usability (to the contrary), it's a fashion statement. That fashion statement comes at a cost. And that cost is much lower contrast.
During my career as a software developer (since the late 1980s) I did create widget themes for visually impaired users. Yes, I know a bit about that, and now in my late 50s my eyesight isn't as good as it used to be.
We had a user working for a customer, for example, who could only read text that was huge (3-4 times as large as the normal font) and in bright neon colors on a black background. We made - with his cooperation and constant input - a widget theme especially for him and his huge monitor. But it was unusable for everybody else; way too much contrast, screaming colors, and an aesthetic disaster zone. It worked for that user, and for him alone.
Years later, I added something similar to YaST, the SUSE Linux installation and system administration program (I was in charge of the user interface engine back then), and right off the bat, we knew we'd have to provide several widget themes for different kinds of visual impairment. It's still there, and these days there is even an icon button in all YaST screens to switch widget themes.
But none of those special widget themes are suitable for everybody, much less for users without vision impairment. There is no catch-all that works for everyone. And then, there are the true fashionistas who just want a cool-looking desktop and switch it to a dark theme for that reason, usability be damned.
Good user interface design is always a balancing act, and it comes with lots of compromises. Nowhere else is it more true that you can't be everybody's darling.
So, if you personally have special needs in that area, and you know how to build software, please go ahead and git-clone the repository and exchange that color that you can't read well for one that you can, and then simply build your own personal version of QDirStat. That's the power of Open Source.
But a solution for everybody is very unlikely to work.
Also, it's not as if hyperlinks were everywhere in QDirStat. It's in that message panel (which you get mostly when you were trying to read a directory tree where you don't have permissions for every directory), and in the breadcrumbs widget where you see and quickly switch the full path of the current directory. And in the "About..." dialogs in the "Help" menu.
Hey Stefan,
Well, I couldn't help it ... :p ... as all I had to do was make the one change, building the app truly was dead-easy. Heck, it took longer to download the Qt dev bits than to build it.
Any chance you'd be game to tweak the color for the link to say color:#1d96b9 - I believe this is the same color as the breadcrumbs. I used my color picker to snarf the color. Hard to do with characters.
Check it out ... swanky!
ps: I'm fundamentally lazy so I don't want to really fork and keep it up to date but ...
If it's a change that subtle, I think that should work. I'll just have to check if it still works in the normal (light) theme.
Notice that this affects only that one location in the panel message.
Old:
New:
This is a bit less contrast in the normal (light) theme, but still acceptable.
In the BreadcrumbsNavigator widget, this still uses the default which is the same blue as in the "old" screenshot.
https://github.com/shundhammer/qdirstat/blob/master/src/BreadcrumbNavigator.cpp#L99-L131
html += QString( "<a href=\"%1\">%2</a>" )
.arg( crumb.url )
.arg( qHtmlEscape( name ) );Notice that this code doesn't do all that artificial QSS styling like that HTML code that Qt Designer automatically inserted, including explicitly setting color:#0000ff;. I would expect it to use the widget theme's defaults in that case.
Hi Stefan,
The breadcrumbs follow the current KDE Colors theme found at systemsettings > Appearance > Colors. Which is obviously great.
In the VM I stood up, I am switching between the various supplied openSUSE TW themes and the Details link is playing nice.
Thank you so much!
Please let me know if you'd like me to add screenshots with the various themes to the screenshots page. It's the least I can do to help out.
This made me think I'd try to reduce that HTML code from panel-message.ui to just a simple <a href=...> without all the <span style=...> stuff. Then it should also simply follow the theme, which I had thought it did in the first place.
But alas, no, Qt Designer insists in adding that stuff again the moment you click "Save".
Talk about "artificial intelligence" - or, more likely, "artificial stubbornness". ;-(
As for the screenshots, for one of the next releases I think I'll have to either redo them all so they become consistent again; right now it's a wild mix of different desktop / window manager themes. I am also not sure if they haven't become too many over the years.
Please try branch huha-force-href-theme-style.
This beats Qt Designer's artificial stubbornness into submission; just to show it who the boss is here, man or machine. ;-)
This uses very plain HTML without frills (in particular without hard-coded styling) which should then use the theme's default, so if the theme is well-behaved and has an appropriate color for hyperlinks, it should use the one defined there, rather than using a different hard-coded override which the first approach did.
I tried in my environment (openSUSE Leap 15.4 + Xfce4) with half a dozen dark themes, but not a single one of them offered a different hyperlink font color than the default #0000ff blue. But IMHO that is an oversight in those themes.
Since you wrote that the BreadCrumbs widget works fine for you, and you can read the links there, it should now use the same font color.
Please try.
OK, merged to master.