Bug 303786 - Regression: Search & Replace background colors hardly visible
Summary: Regression: Search & Replace background colors hardly visible
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: general (show other bugs)
Version: 3.8.90
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-19 10:20 UTC by Pascal d'Hermilly
Modified: 2012-10-28 17:29 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pascal d'Hermilly 2012-07-19 10:20:47 UTC
Kate stopped highlighting the results when you click the "Find all" button to search for a word. 

Reproducible: Always

Steps to Reproduce:
1.Open kate and fill some text. E.g.
"My background
Super background color
Why background wallpaper"
2. click Menu -> Edit -> Find
3. try to find "background"
4. click the arrow on the right to get more options
5. click "find all"
Actual Results:  
no highlight of found items

Expected Results:  
highlighted found results.

To me this is quite big since I use it a lot...
Comment 1 Dominik Haumann 2012-07-19 11:36:12 UTC
Might it be that the highlight is there, but it's very light? You can change the colors in the config dialog. Please check.
Comment 2 Pascal d'Hermilly 2012-07-19 12:50:31 UTC
Indeed. It quite goes against the word highlight eh? :-)
I can fix it for me, but we should consider a better default highlight color..
Comment 3 Dominik Haumann 2012-07-19 12:58:31 UTC
Unfortunately, I don't know how to get a better default highlight color.
Currently, I use the color from system settings of the Color Set "View", the background of the "Neutral Text". It is very decent, and on my screen it's visible.

Having a color with more contrast would be nice. Is there a better way to calculate the color? The same applies to the replace color.
Comment 4 Pascal d'Hermilly 2012-07-19 13:14:31 UTC
The problem is that there is no real highlight background in the color scheme.
Perhaps choosing a contrasty yellow and green that you like is better?
Comment 5 Christoph Feck 2012-07-19 13:49:58 UTC
You can use KColorScheme to get a suitable background color for the "view". Pick one you like most from System Settings, but I would suggest to use "Positive".
Comment 6 Dominik Haumann 2012-07-19 13:54:38 UTC
I use Positive for replaced text.

So for me, the bug report boils down to how to get a better contrast to the background color. Maybe KColorUtils help here, although I don't see how right now:
http://api.kde.org/4.8-api/kdelibs-apidocs/kdeui/html/namespaceKColorUtils.html

There is KColor::contrastRatio, but this alone won't help.
Comment 7 Matthew Woehlke 2012-07-19 18:00:20 UTC
Assuming a: you aren't dealing with some funky syntax-based background colors, and b: your system color scheme is reasonable, then View->{Positive,Neutral} Background (*not* Text) should be adequate colors. Text flavors thereof are going to tend to be illegible, at least on light-on-dark schemes (and are also an a11y violation). For some syntax parts, they'll be the /same/ color as the text.

If those don't work, I'd be inclined to consider it a bug in the color scheme system and

That said, on my system (KDE 4.8.4, katepart 3.7), katepart seems to be using Qt::yellow and Qt::green? (My positive/neutral colors are indeed shades of yellow and green, but they're clearly distinct from "pure" yellow/green, and the colors I'm actually seeing are definitely not from my color scheme. Also, the replaced text background gives a distinctly illegible result.)
Comment 8 Dominik Haumann 2012-07-19 20:53:43 UTC
So what's the correct solution? Use KColorUtils::contrastRatio, and check whether the ration gets better with lighter or darker and then use this color if we get a ration above a certain threshold?
Comment 9 Matthew Woehlke 2012-07-19 22:10:51 UTC
Well... colors are tricky :-).

I'd say that's probably the best thing to do, yes. If there's a reasonable way to cache it (and/or if it could be added to the color options in a way that makes sense - the hard part there being that, for Oxygen at least, I notice it needs to be different depending on the role), I'd prefer for KColorScheme to do this when generating the background colors, to ensure a reasonable contrast.

Anyway, if you do it in katepart, I'd suggest using KCU::tint (as opposed KCU::mix), which is how the background colors already get generated. And possibly cap the tint amount to 0.7-ish to avoid the problems from using a foreground color as a background color.
Comment 10 Matthew Woehlke 2012-07-19 22:19:58 UTC
I've also created bug 303825, which possibly supersedes this.
Comment 11 Pascal d'Hermilly 2012-07-20 07:47:30 UTC
For me, "Text positive" and "Text neutral" doesn't have anything to do searched and replaced text. They would be hints for how to use colors to let user interpret text better.

I think if we are going to be using colors different from the color scheme anyway then we might as well just use the effective yellow and green.
Comment 12 Matthew Woehlke 2012-07-20 16:13:14 UTC
The color scheme names are meant to be recommendations, i.e. you should choose the one that makes the most sense. In some cases (e.g. coloring the URL line edit for website SSL verification), there is a good correspondence. Other times (e.g. katepart) there is not, but you should still prefer to use the scheme and make the best choice you can.

I would argue using Positive for replaced text makes sense... a successful replacement is a reasonable interpretation of "positive". Using neutral for found text is more of a gray area; I could argue for it being a "pending replacement", but I could also argue for using Active instead. However, I would say that is less important than actually using the scheme.

Please DO NOT revert to using Qt::yellow and Qt::green; these are illegible with my color scheme (probably most light-on-dark schemes) and that they are non-configurable is an a11y violation. Using the system color scheme is The Right Thing To Do; it's a bug that the system scheme colors are inadequate.
Comment 13 Dominik Haumann 2012-07-25 16:20:56 UTC
Git commit cbbccc36740c31a1e9aecc8cc69cc2889c4fa9ed by Dominik Haumann.
Committed on 25/07/2012 at 18:16.
Pushed by dhaumann into branch 'KDE/4.9'.

last minute fix for KDE 4.9: hard code search&replace colors

workaround, until we have a better solution

M  +2    -2    part/schema/kateschemaconfig.cpp
M  +2    -2    part/utils/kateconfig.cpp

http://commits.kde.org/kate/cbbccc36740c31a1e9aecc8cc69cc2889c4fa9ed
Comment 14 Dominik Haumann 2012-10-28 17:12:59 UTC
Git commit 2356a11a7f4d78f61185d89f25c120af6f90ce1e by Dominik Haumann.
Committed on 25/07/2012 at 18:16.
Pushed by dhaumann into branch 'master'.

last minute fix for KDE 4.9: hard code search&replace colors

workaround, until we have a better solution

M  +2    -2    part/schema/kateschemaconfig.cpp
M  +2    -2    part/utils/kateconfig.cpp

http://commits.kde.org/kate/2356a11a7f4d78f61185d89f25c120af6f90ce1e