| Summary: | Unreadable text on tooltips in KDE 4.7 [patch] | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | nucleo <nucleo> |
| Component: | Usability-Themes | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, cfeck, jrussell_88, j_kolberg11, photographer505-bug, rdieter |
| Priority: | NOR | ||
| Version: | 2.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 2.4.0 | |
| Sentry Crash Report: | |||
| Attachments: |
Digikam 2.1.1 with
white text on black background unreadable tooltips in libreoffice patch to use QPalette::ToolTipText in place of QPalette::Text where appropriate |
||
All color in digiKam are relevant of KDE color scheme set in KDE control center. Look into Settings/themes menu entry Gilles Caulier Created attachment 64335 [details] white text on black background (In reply to comment #1) > All color in digiKam are relevant of KDE color scheme set in KDE control center. There is default theme in Settings/themes (Oxygen). But KDE applications such as systemsettings have tooltips with readable text (white on black background). Which KDE color theme you use exactly ? Oxygen ? Because it work fine here. Do you use a KDE global theme too, which assign also some colors to application? Gilles Caulier This is LiveCD with default settings in KDE 4.7.1. Oxygen colors and Air desktop theme used there. Same for me here, and no problem... KDE 4.6.5. Gilles Caulier This problem appears in KDE 4.7, no such problem in 4.6. I can confirm (using digikam-2.1.1), settings->themes->oxygen makes popups (very close to) unreadble on kde-4.7.x. pretty much any other theme works better (oxygen cold, for example). when I get a chance, I'll try to diff the kde-4.6 vs kde-4.7 oxygen color scheme Please note there is no real custom drawing involved:
{
QStylePainter p(this);
QStyleOptionFrame opt;
opt.init(this);
p.drawPrimitive(QStyle::PE_PanelTipLabel, opt);
}
QLabel::paintEvent(e);
code is mostly copied from Qt (we render some details ourselves, and the relevant Qt code is not public)
OK, did some digging, and kde-4.7's Oxygen.colors changed a bit here, https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/602a3c2c9e0cb2a32184139adfd2fa1dcf712aeb In particular, the [Colors:Tooltip] section's BackgroundNormal changed dramatically. Poking oxygen folks to find out what's up with that. reassigning to oxygen for real this time, for feedback on comment #10 As a matter of fact, perhaps the [Colors:Tooltip] BackgroundNormal and ForegroundNormal values were inadvertently swapped? swapping them back does indeed make things look much better again for me. Applications should render QPalette::ToolTipText on QPalette::ToolTipBase if they only support QPalette. Applications that support KColorScheme can use the additional roles valid for the tool tip's background. I see no bug in Oxygen themes. Created attachment 65916 [details]
unreadable tooltips in libreoffice
The same problem with tooltips in Libreoffice with libreoffice-kde installed.
Fair nuf, back to digikam then to implement the suggestion. nucleo, please report to libreoffice-kde developers (that's probably a distribution specific add-on). If they respect the KDE/Qt colors, they should respect all of them, not only the background. Heh, I even see a call in digikam's ditemtooltip.cpp with a commented out: //setForegroundRole(QPalette:ToolTipText); You can also use http://opendesktop.org/content/show.php?content=90034 to check for hard coded black colors or wrong color role usage in applications. The tool tips with that theme have a light yellow background, but should also have a dark yellow (brown) text, not a black or blue one. So Libreoffice issue is libreoffice bug (specific to -kde) Digikam issue is digikam bug (right ?) So closing as downstream. But why closing bug against digikam without actual fix in digikam? Reopen, because it is still valid for digikam. sorry :) I thought it was reassigned to oxygen in the process :) Been too quick at closing. Darn, per comment #17, uncommented the setForegroundRole(QPalette:ToolTipText); call in libs/widgets/common/ditemtooltip.cpp , and rebuilt digikam, but it didnt seem to help any. :( Rex, can you check if changing QPalette::Text to QPalette::ToolTipText in the DToolTipStyleSheet constructor (same file) helps? (Only in the last four cases, because the first case correctly sets a background color, too.) DItemToolTip::renderArrows() also uses QPalette::Text, but not sure on which background they are rendered. preliminary results: win! thanks! I'll do a wee bit more testing, and post a patch shortly. Thanks in advance Rex Gilles Caulier Created attachment 65930 [details]
patch to use QPalette::ToolTipText in place of QPalette::Text where appropriate
Here's a minimal patch that seems to fix all problems for me, tested under various color schemes on kde 4.7
Git commit 007759d0a1d80d11c17a3cc005d80c803d0e9dfa by Gilles Caulier. Committed on 22/11/2011 at 17:20. Pushed by cgilles into branch 'master'. apply patch #65930 from Rex Dieter BUGS: 283572 BUGS: 265554 M +4 -4 libs/widgets/common/ditemtooltip.cpp http://commits.kde.org/digikam/007759d0a1d80d11c17a3cc005d80c803d0e9dfa *** Bug 292902 has been marked as a duplicate of this bug. *** *** Bug 281108 has been marked as a duplicate of this bug. *** *** Bug 298717 has been marked as a duplicate of this bug. *** |
Created attachment 64324 [details] Digikam 2.1.1 with Version: 2.1.1 (using KDE 4.7.1) OS: Linux Text on tooltips is unreadable in KDE 4.7 with Oxygen colors. Reproducible: Always Steps to Reproduce: Enable tooltips for images in albums. Actual Results: Black text in black tooltips is invisible. Expected Results: Text should be visible. The same problem in Digikam 2.2.0. No such problem with Oxygen colors in KDE 4.6.