[Regression?] Font color for titlebars black regardless of titlebar color, xfwm theme chosen, etc; significantly harder to see than prior versions #5800
Comments
GSF1200S
added
P: default
|
The change was supposed to fix black on black issue, and also improve the contrast for other window colors in the default theme. It's true that it doesn't really go well with themes other than default one, although I had an impression that they were pretty broken already (re-coloring the decorations often caused a similar contrast reduction as with black on black). A more correct solution would take care to re-color both title and decorations so that high contrast is retained. I'm not sure how exactly to do that, though. |
|
@marmarek- Its really with both inactive and active. Im not sure what your displays are, but I run an X230 with Qubes... and the one I have has a real crappy TN display. Its impossible to see the titlebar text in sunlight unless I have the screen pointed directly at my face (and I'm near it). Beyond that even in more favorable conditions, its pretty hard to see. Its worth noting I don't wear glasses and my eyesight is (so far) 20/20, so this isn't just a "Im blind" thing. I get that you did this to fix a problem, but its worth noting that black is really only used for Templates and Vault... and this change negatively effects the visibility of titlebars I use more often (though I understand others needs might be different). Its a little more legible if I make the font size 2-3 sizes larger (eg Sans 9 to Sans 12). Is this a simple thing that could be handled by a custom config file or something? @pwmarcz- Yeah, the Default theme is a little better wrt contrast. I don't want to sound pedantic here but my X230 (which is also the base of any Qubes certified hardware last I checked) has really limited screen space. Anything that eats space- especially something as minimally useful as a titlebar- hurts (especially with vertical screen space). I can't get xfwm4 to do no titlebar with a border so... Not sure how to respond here guys :D I filed this initially because I saw an immediate reduction in contrast and a difference between AppVMs and dom0, figured it was a bug, tried some stuff, and then set out for github. Seeing as its something you guys intended it might just be the way things need to stay :) Its bad enough though that this along with the youtube fullscreen bug might be enough to get me working on an Awesome setup once Qubes 4.1 is out :) |
|
I hear you. I think it's clear that this titlebar change needs improvement; the contrast is not great with the default setting either (e.g. white-on-blue would be better than black-on-blue). I want to take a look at it sometime and try to make non-default themes work a little better. However, if I make changes, it'll probably be for 4.1 only - unfortunately that part of xfwm4 changed enough that it's pretty difficult to port changes to the old version. |
|
What about changing font color to white only on black background and keep the theme one for other vm colors (on R4.0) @pwmarcz ? |
|
So, a rollback of (half of) the current change? Sounds good, let me try... |
I looped through the entire |
|
It would be nice to just have (in)active_text_color in /etc/qubes/guid.conf. |
|
@hexagonrecursion The window decorations are modified separately, go to |
This is a partial revert of the change introduced in d2e53b3. The title colors look improve the text visibility for the default theme (particularly inactive text); however, they make the sitation worse if you want to use a different theme. For now, override the title only in the black-on-black case to fix the usability regression. In 4.1, I'll be trying to do something more helpful to the user. See discussion in QubesOS/qubes-issues#5800.
|
@marmarek I made the fix for 4.0. For master, I will experiment a bit with adapting the title colors to theme, because the current Qubes behaviour is pretty bad in my opinion (especially for inactive windows). |
Instead of overriding the color always, do so only for the black title. Otherwise, try to improve the contrast. See QubesOS/qubes-issues#5800.
|
Automated announcement from builder-github The package |
|
@marmarek I actually had been wanting to file a similar issue for a while. For each Qube color, I'd like to spec a unique high-contrast color for the text and icons that sit on top of the windows. Could that be possible or not a complete pain the butt? Yes, this is a big problem to varying degrees, depending on the VM color—but, yes, black is the worst. I have yet to sit down to determine the best contrasting hex value for each qube, but could totally do that over the next few days. |
|
@ninavizz Wouldn't the best color depend on the window theme as well? I posted some screenshots in QubesOS/qubes-desktop-linux-xfce4-xfwm4#7. |
|
@pwmarcz You are totally correct, thank you for that flag! Yeah, that's part of why shadowing is used on titles in many window stylings. Could that be an option, here? Some OS window themes (generally, not specific to XFCE or Qubes) can do text shadows with black, or with a very dark shade of the color; which then reduces text legibility. A -1px y-axis offset text shadow that is white, or a 1px y-axis offset text shadow that is dark, or vice-versa, or much bigger 0px-offset text shadows with a lot of blur, are typically employed to help with legibility in those situations. Part of why the Linux inclination towards infinite customization, kind of drives me bonkers. It'd drive me less bonkers, if there could be more of a commitment to always ship with the cleanest and most usable solution to things. :) I'd honestly prefer if the Atlanta theme could be the default Qubes ships with, as it's the "cleanest" XFCE theme I've found on my own Qubes laptop. Could that be a partial solution to this? I think it has the least gradients and cleanest icons, of all the XFCE themes. |
|
Something I also did not include in the above: all of the themes @pwmarcz identified in the PR as "broken," are themes without any gradients on the title or side bars. Without the gradients, it's easier to disambiguate the colored windows from one another... and the window icons are usually clearer/cleaner. Which is why I like the Atlanta theme. It seems to me that part of the decision in this Issue, needs to be if there's an interest in standardizing around a theme with gradients in the window frame (which is how the current default theme works), or to change that to ship with a theme (such as Atlanta) that does not have gradients on the window frames. Thoughts? |
|
I would be happy if we could find something simple that works reasonably well for any theme. The outlines might help. Maybe something like always white text with dark/black outline? I'll experiment. As for changing the default theme... I can imagine this is more difficult because people are used to the default theme already. On the other hand, if it improves the situation clearly, it might be a good idea, and what better time to do it than launching a new version. The problem I see with Atlanta theme specifically is that Qubes colorization mangles it, making the "white" and "colored" parts of window decoration the same. As a result, the window icon becomes almost invisible, and the window buttons are not very clear... maybe the colorization would work better if it was HSL based, not HSV? @marmarek what do you think? |
Okay, that doesn't really help. White text with dark outline (the way XFWM draws it), on a white background, looks pretty bad. |
@pwmarcz- maybe I'm missing something here, but after pulling your fixed version from testing I'm not having contrast issues at all... at least with regards to font color/text. So because the resolution sucks on the X230, I use the Bluebird xfwm theme. It has a very thin border, it has no gradients (I like flat themes) and the titlebar is pretty small while still being usable. The only contrast issue I have is the minimize and maximize buttons on black titlebars (generally templateVMs or Vault) being difficult to see, especially if I'm not looking at my crappy TN display head on. Other than that, I'm not seeing any significant contrast issues now. I admit that inactive titlebar text isnt great, but its still pretty decent IMO. Many other themes are really bad with inactive titlebars. Can you try the Bluebird theme to see what I mean? The contrast seems fine to me now regardless of whether the border is orange, green, yellow, purple, blue, etc except, again, the min/max button on black titlebars. I went through the other themes- many were bad enough that I didn't bother taking notes. Of the ones where font text contrast is decent, this is what I noted (subjective in some ways I admit): Adept (ugly IMO, button contrast sucks with dark titlebars) Elberg (I find it hideous but w/e; poor button contrast black titlebars), Galaxy (not much distinguishment between active/inactive; poor button contrast black titlebars), Gorilla (also hideous to me :P ), Meenee (pretty cramped; again bad contrast for buttons), Pirahna (good, but crappy contrast for buttons template/vault borders and a very thick border), Today (pretty ugly IMO, and again Vault/Template buttons have poor contrast). Bluebird is one of the few where even with a dark titlebar the close button is easily visible and again, the text is decent to great with regards to contrast. I get that you guys want something that adapts font contrast to be good for the theme used, but perhaps in the meantime modifying the menu/min/max buttons on Bluebird to a brighter white (along with whats in testing) and setting that to default would give users something usable. I admit my bias here as I like the theme and like simple non-gradient type themes, and I also acknowledge that others may find it a hideous theme or unacceptably plain. I yield to your judgements here- I just figured I'd throw out what I noticed. Thanks for the concern/work on this issue :D |
|
I'll check out Bluebird tomorrow. I also am biased in favor of not having gradients on title-bars, for the problems summarized above. Another issue I noticed wrt font coloring, is that when a window is not in focus all the title-bar text becomes grey—regardless of the VM's color. Would love to discuss how the coloring of fonts works across themes next time we do a call @marmarta. Ya, UX things hard to do async in text. Thx for filing this issue @GSF1200S!! If you're actually an old-skool Suzuki vs a real human, you get extra points. |
|
Automated announcement from builder-github The package Or update dom0 via Qubes Manager. |
|
I'm also seeing this on 4.1. |
Use a perceptual color space instead of HSV when colorizing window decorations, and retain more of the original decorations' lightness. This makes most decorations slightly less dark, improving contrast, removes the need for specialcasing black, and fixes the treatment of gray. In addition, try to determine light/dark color depending on the original window manager theme. Most themes should look OK now. See QubesOS/qubes-issues#5800
Use a perceptual color space instead of HSV when colorizing window decorations, and retain more of the original decorations' lightness. This makes most decorations slightly less dark, improving contrast, removes the need for specialcasing black, and fixes the treatment of gray. In addition, try to determine light/dark color depending on the original window manager theme. Most themes should look OK now. See QubesOS/qubes-issues#5800.
Use a perceptual color space instead of HSV when colorizing window decorations, and retain more of the original decorations' lightness. This makes most decorations slightly less dark, improving contrast, removes the need for specialcasing black, and fixes the treatment of gray. In addition, try to determine light/dark color depending on the original window manager theme. Most themes should look OK now. See QubesOS/qubes-issues#5800.
Use a perceptual color space instead of HSV when colorizing window decorations, and retain more of the original decorations' lightness. This makes most decorations slightly less dark, improving contrast, removes the need for specialcasing black, and fixes the treatment of gray. In addition, try to determine light/dark text color depending on the original window manager theme. Most themes should look OK now. See QubesOS/qubes-issues#5800.
Use a perceptual color space instead of HSV when colorizing window decorations, and retain more of the original decorations' lightness. This makes most decorations slightly less dark, improving contrast, removes the need for specialcasing black, and fixes the treatment of gray. In addition, try to determine light/dark text color depending on the original window manager theme. Most themes should look OK now. See QubesOS/qubes-issues#5800.
|
See QubesOS/qubes-desktop-linux-xfce4-xfwm4#11 for a new proposal: tweak title contrast (use black or white title color, depending on original theme), and change the way decorations are colorized (make the lightness an average of theme lightness and original lightness). |
|
@pwmarcz See cross-linked issue above... I'd love your thoughts! I REALLY love your PR, as a step towards improvement!! The focus/background thing seems to be a big problem with the coloration with Qubes, as a more general thing I wanted to address with creating a whole other theme... but for working with existing themes, I really did your PR!! :) |
|
I'm playing around with arc-dark in R4.1, and most window titles are so dark they're almost indistinguishable from the dark-themed window. Dom0 and any black-colored qubes display with a lighter title that is easy to read, but all others do not. Perhaps because the window decoration "should" be red for example, but is actually dark from the theme? I suppose qubes isn't supposed to work at all well with dark xfce themes since that loses the colored window decorations. |
|
I created #6414 in part, to address this issue. I don't feel that "further tweeks" within any exiting themes, will really fix the problem. I believe Qubes just needs its own XFCE theme for windows. That said, a volunteer developer would likely need to do that work (I'm not a developer). |
|
IMHO some titlebar colors have worse contrast in 4.1 than in 4.0. Theme: Nodoka I think the old 4.0 white text is better for these: I think the new 4.1 black text is better for these: Same: |
andrewdavidwong
added
the
eol-4.0
|
This issue is being closed because:
If anyone believes that this issue should be reopened and reassigned to an active milestone, please leave a brief comment. |
Qubes OS version
Qubes 4.0
Affected component(s) or functionality
xfwm4.x86_64 1000:4.12.4-2.fc25
I did not have this problem until the above package dropped in my system May 6th, 2020.
Brief summary
When opening a terminal, xfce4 settings, qube manager, etc on dom0, the text color reflects the theme you've chosen for the window manager. You can go into the themerc of the style you are using and change the active font color if you want... and the change will be reflected in a [Dom0] window. For my case, I use the Bluebird theme.
No change to active text color above has any effect on windows not [dom0]; worse, the contrast is often terrible. For purple, orange, yellow, green, red, and blue titlebar colors, the titlebar text is black when active and dark gray when inactive. This is much more difficult to see then it used to be in the past. For black titlebars, the text is white or very light gray; by default black is the color of TemplateVM and Vault titlebars.
To Reproduce
As above...
Expected behavior
Active titlebar text should be the same between dom0 and AppVMs.
Actual behavior
Active titlebar text is not the same between dom0 and AppVMs, and the contrast is often poor. It is not the same even with, say, similar titlebar colors e.g. both blue.
Screenshots
I dont think this is necessary, but if so I will post one for you.
Additional context
The only reason I'm filing this bug report is that it is extremely annoying from a usability angle... especially when the screen is in direct sunlight. Contrast is a good thing- a darker orange and a bright white contrast better than a darker orange and black. It forces me to get right up on the screen to read the titlebar text.
Solutions you've tried
I tried changing themes, and moving Bluebird theme gtkrc into my user's .config/gtk-2.0 directory. I don't know what else to try... I can get dom0's windows to have the active font color I want in the titlebar by changing the themerc, but it has no effect on any other windows (TemplateVMs, AppVMs, etc)
The text was updated successfully, but these errors were encountered: