GNOME Bugzilla – Bug 769879
[HighContrast(|Inverse)] tooltips problems
Last modified: 2017-10-05 18:42:29 UTC
Tooltips suffe some problems when using HighContrast or HighContrastInverse themes. I’m not sure all of them could be solved by the theme, but at least some could. * In HighContrast (not sure if HighContrastInverse has the same thing, but if it has it’s dark on dark), there’s a weirdness in the top-left and top-right corners of the tooltip, where something has a border with radius covered by the tooltip background. Adding a “tooltip > * { border-radius:0; }” solves the problem, but I don’t know how to determine the widget that is causing that problem. * In HighContrastInverse only, a light/white border would probably help to correctly read the tooltip. * In HighContrast, the shadow around the tooltip is too big, and doesn’t look really good. * In both themes, the shadow that is around the tooltip (HighContrast) or the space reserved for it (HighContrastInverse) is probably too big, resulting sometimes in the tooltip eating a click on the widget that made it appear. I had notably the problem in gnome-logs, that has big tooltips placed at a fix position related to the row. Maybe a gnome-logs bug?
(In reply to Arnaud B. from comment #0) > Tooltips suffe some problems when using HighContrast or HighContrastInverse > themes. I’m not sure all of them could be solved by the theme, but at least > some could. > > * In HighContrast (not sure if HighContrastInverse has the same thing, but > if it has it’s dark on dark), Yup, inverse will be affected too, as it uses the same _common.scss for nearly everything. > there’s a weirdness in the top-left and > top-right corners of the tooltip, where something has a border with radius > covered by the tooltip background. Adding a “tooltip > * { border-radius:0; > }” solves the problem, but I don’t know how to determine the widget that is > causing that problem. This might be related to https://bugzilla.gnome.org/show_bug.cgi?id=736155 where it looks like only Adwaita got the fix involving a new .background selector. See also https://bugzilla.gnome.org/show_bug.cgi?id=784421 for issues with custom tooltips in Adwaita - I'm sure HighContrast has the same problems, but all the other ones you mentioned make it hard to identify them individually! ;)
Created attachment 360951 [details] [review] HighContrast: Actually style tooltips... Isn't the problem as simple as this? HighContrast: Actually style tooltips... We need to select on the widget itself too, not just other things with the .tooltip class. Matthias previously made a commit just changing .tooltip to tooltip, whereas here I keep both, as I *think* the class is still used in some cases. This makes tooltips styled like Adwaita, with a transparent black background, white text, and round corners - instead of just black text on a white rectangle with (at least on win32) no border.
Created attachment 360953 [details] [review] HighContrast: Actually style tooltips... missed a *
Created attachment 360954 [details] [review] HC: Give tooltips a border for contrast on Inverse (In reply to Arnaud B. from comment #0) > * In HighContrastInverse only, a light/white border would probably help to > correctly read the tooltip. There's an old commented-out line that is at least an improvement, giving us a grey tooltip that lets us see where tooltips begin/end - at least until we resolve that other comment, "//FIXME proper color" on the background ;-) We could always tweak $borders_color per-variant if needed, too. Here I also took the liberty of reducing its border-width from 2px to 1px. I've only tested this on Windows, so maybe it causes some insane triple border on Linux; this is a perilous area IIRC from other bugs.
Created attachment 360980 [details] [review] HC: Copy working tooltip code from Adwaita & tweak There were various problems, like only selecting on .tooltip and not the widget node tooltip, not being specific enough for tooltip.csd, etc. So, specific theming was absent, and default popup window styles got applied This commit copies in the better working tooltip CSS from Adwaita, then applies a couple of changes to make things fit better in the HC themes: • Reduce the transparency of the tooltip, so we achieve higher contrast • Drop the black text-shadow, as it is not useful on this more black bg Note: we may then need to restore some of this the .tooltip class. But it is unclear what needs done there. While Adwaita is not doing it, we are better not to confuse by keeping it in HC only; we should try to be as close as possible, to make it easier for HC to keep up with Adwaita. -- This is probably good to push just to get something better in, then I will let the people with the actual design skills refine wherever they might want to. :)
I'd welcome comments on what you think, but as far as I can tell, this patch appears to resolve all of these, as follows: (In reply to Arnaud B. from comment #0) > * In HighContrast (not sure if HighContrastInverse has the same thing, but > if it has it’s dark on dark), there’s a weirdness in the top-left and > top-right corners of the tooltip, where something has a border with radius > covered by the tooltip background. Adding a “tooltip > * { border-radius:0; > }” solves the problem, but I don’t know how to determine the widget that is > causing that problem. This is fixed. It's probably because HC was only selecting on things with class .tooltip before, not the tooltip widget node. I didn't analyse the old code too much, though; it was just kinda broken. > * In HighContrastInverse only, a light/white border would probably help to > correctly read the tooltip. Now we have a border of $borders_color, i.e. a nice mid grey. > * In HighContrast, the shadow around the tooltip is too big, and doesn’t > look really good. > * In both themes, the shadow that is around the tooltip (HighContrast) or > the space reserved for it (HighContrastInverse) is probably too big, > resulting sometimes in the tooltip eating a click on the widget that made it > appear. I had notably the problem in gnome-logs, that has big tooltips > placed at a fix position related to the row. Maybe a gnome-logs bug? Now we have no shadow!
Attachment 360980 [details] pushed as 8abdbfe - HC: Copy working tooltip code from Adwaita & tweak