Summary: | ticks become very dim if shading decreased | ||
---|---|---|---|
Product: | [Plasma] Oxygen | Reporter: | temporary987 |
Component: | style | Assignee: | Hugo Pereira Da Costa <hugo.pereira.da.costa> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | aacid, hugo.pereira.da.costa |
Priority: | NOR | ||
Version: | 5.0.1 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
URL: | https://forum.kde.org/viewtopic.php?f=66&t=121663 | ||
Latest Commit: | http://commits.kde.org/kde-workspace/7f3274a5de569bf03103e20aaa1d595960b6f59d | Version Fixed In: | 4.11.13 |
Sentry Crash Report: | |||
Attachments: |
patch for oxygen-gtk2
patch for oxygen-gtk3 attachment-5836-0.html |
Description
temporary987
2014-07-14 10:26:23 UTC
Is there anybody here? *** Bug 339177 has been marked as a duplicate of this bug. *** there is no point filling a new bug report for new kde version. Bug is aknowledged, no time was found to fix it so far, sorry. Thank you for your response. Actually, this is the only thing which prevents me from using oxygen/oxygen-gtk. I would be very happy, if you could fix it. Probably, it is possible to fix this bug by hardcoding color of this checkmark? I know this is not a solution for everyone (because of different color schemes), but if you told me, how to do so, I would like to follow your advice. (In reply to Sergey from comment #5) > Probably, it is possible to fix this bug by hardcoding color of this > checkmark? I know this is not a solution for everyone (because of different > color schemes), but if you told me, how to do so, I would like to follow > your advice. Hardcoding a color is no-go (because it needs to change depending on color palette) what is wrong right now is how color is calculated based on current palette and contrast ratio temporary solution could be to use simply QPalette::color( QPalette::WindowText ) (with no contrast nothing) If you want to give it a shot, look after 'renderTicks" or something like that in oxygenstyle.cpp On my time I'd rather spend some time to 'fix' the contrast dependent aspect. But it takes some time ... Hello, it's me again. I understood nothing in oxygenstyle.cpp (I'm no programmer), but this bug really annoys me, so I'm ready to make a financial contribution as a thank you for fixing this bug. I don't know, if it is appropriate or not... Financial support wont help. Time would. Now I must say I misunderstood the bug report to start with, thinking you were talking about slider ticks and not checkboxes marks. And then I could not really reproduce. Finally figuring out you were talking about chexboxes (sorry for being slow), as well as arrows, etc. I guess I can come with a fix rapidly and agree that the color to be used should be the foreground color, period, with no contrast fading. There should be a fix around rather soon. Git commit 24163dde5d45d6611285884414ece9fe7797ef67 by Hugo Pereira Da Costa. Committed on 08/10/2014 at 07:49. Pushed by hpereiradacosta into branch 'master'. improved contrast for rendering checkbox marks, arrows, etc. M +1 -1 liboxygen/oxygenhelper.cpp http://commits.kde.org/oxygen/24163dde5d45d6611285884414ece9fe7797ef67 Git commit 7c2e5e7742bdf120942e2aaf80086972403b80c4 by Hugo Pereira Da Costa. Committed on 08/10/2014 at 07:49. Pushed by hpereiradacosta into branch 'Plasma/5.1'. improved contrast for rendering checkbox marks, arrows, etc. M +1 -1 liboxygen/oxygenhelper.cpp http://commits.kde.org/oxygen/7c2e5e7742bdf120942e2aaf80086972403b80c4 Git commit 7f3274a5de569bf03103e20aaa1d595960b6f59d by Hugo Pereira Da Costa. Committed on 08/10/2014 at 07:52. Pushed by hpereiradacosta into branch 'KDE/4.11'. improved contrast for rendering checkbox marks, arrows, etc. M +1 -1 libs/oxygen/oxygenhelper.cpp http://commits.kde.org/kde-workspace/7f3274a5de569bf03103e20aaa1d595960b6f59d Created attachment 89043 [details]
patch for oxygen-gtk2
Created attachment 89044 [details]
patch for oxygen-gtk3
Thank you very much for your commits! I have built patched sources and everything is ok now. However, gtk2 and gtk3 apps still need to be fixed. I have looked through their sources and here are the patches which fix the situation for oxygen-gtk2, oxygen-gtk3 (they were created automatically by dpkg-source --commit after I have changed the sources). (In reply to Sergey from comment #14) > Thank you very much for your commits! I have built patched sources and > everything is ok now. However, gtk2 and gtk3 apps still need to be fixed. I > have looked through their sources and here are the patches which fix the > situation for oxygen-gtk2, oxygen-gtk3 (they were created automatically by > dpkg-source --commit after I have changed the sources). Too late :) I already committed patches to gtk2 and gtk3 But thanks for your patches nonetheless. Thank you! These changes will be in use in KDE 4.14.2 tomorrow, am I right? for Qt version, yes, hopefully for gtk no. It is released independently we plan to make a release in the comming week though, due to another serious bug that got fixed. Created attachment 89050 [details] attachment-5836-0.html Ok, great! Anyway, I'm gonna build oxygen-gtk from git :) 2014-10-08 15:10 GMT+00:00 Hugo Pereira Da Costa <hugo.pereira@free.fr>: > https://bugs.kde.org/show_bug.cgi?id=337433 > > --- Comment #17 from Hugo Pereira Da Costa <hugo.pereira@free.fr> --- > for Qt version, yes, hopefully > for gtk no. It is released independently > we plan to make a release in the comming week though, due to another > serious > bug that got fixed. > > -- > You are receiving this mail because: > You reported the bug. > |