Bug 309722 - selected item in dolphin (thumbnail, icon) is tinted in strong monochrome colors
Summary: selected item in dolphin (thumbnail, icon) is tinted in strong monochrome colors
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 2.1
Platform: Ubuntu Linux
: NOR wishlist with 27 votes (vote)
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL: http://i.minus.com/ibsHHOXwfZ1A5V.png
: 325127 (view as bug list)
Depends on:
Reported: 2012-11-08 00:51 UTC by darija
Modified: 2021-03-09 02:18 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:

Examples for different tinting levels of selected items. The 'value' parameter of KIconEffect::colorize decreases from 1.0 to 0.4 in steps of 0.1. (1.35 MB, image/png)
2013-01-08 17:57 UTC, Frank Reininghaus
Removes tinting of icons and draws a selection rectangle around icon and text (1.58 KB, patch)
2013-11-07 16:32 UTC, Frank Reininghaus
Improved version of selection rendering (4.32 KB, text/plain)
2013-11-08 01:33 UTC, Christoph Feck
Produced example screenshot (16.21 KB, image/png)
2013-11-08 01:34 UTC, Christoph Feck

Note You need to log in before you can comment on or make changes to this bug.
Description darija 2012-11-08 00:51:33 UTC
In the scrot linked the first two items show how thumbnails are shaded in the new Dolphin, 4.9.3 under kubuntu 12.10. The third item demonstrates a selected thumbnail in Gwenview, for comparison. The tinting in Dolphin (in this case, the system default for selected background is a light blue) is too strong, rendering the thumbnail (or icon) black and white. When I use the default (Oxygen) colorscheme, it is a strong, unpleasant monochrome blue. 
At first I thought this was a bug, but this thread on KDE forums: http://forum.kde.org/viewtopic.php?f=224&t=108409 resolved that it was a feature.
And I also understood that this feature was introduced in 4.9 as a result of a bug filed on this same bugtracker against the Dolphin tinting "not being strong enough".
I would like to now file this bug to ask the devs to consider finding a compromise solution. What you can see in the scrot is highly unusual, at least I have not come across an app that resolves the tinting in such an extreme visual manner. In my opinion it takes away from the overall UI excellence of Dolphin and should be, so to speak, "toned down".

Reproducible: Always

Steps to Reproduce:
1. Launch Dolphin
2. Select an item (any view mode)
Actual Results:  
Strong, monochrome tinting

Expected Results:  
Moderate, more subdued tinting
Comment 1 Frank Reininghaus 2012-11-29 06:13:27 UTC
Thanks for the detailed bug report! Yes, I agree that the tinting is too strong. We'll try to come up with something better for KDE 4.10.
Comment 2 Frank Reininghaus 2013-01-08 17:57:05 UTC
Created attachment 76313 [details]
Examples for different tinting levels of selected items. The 'value' parameter of KIconEffect::colorize decreases from 1.0 to 0.4 in steps of 0.1.

Sorry for not providing any follow-up information earlier. I did experiment with Peter's idea to make the tinting slightly weaker (the time for any more intrusive changes, which would fix this problem properly, has ended more than 2 months ago for KDE 4.10).

Unfortunately, it's hard to get anything which is really satisfying with this method. The problem is that:

1. In the default settings, both the color of the folder icons and the 'selection color' are slightly different shades of blue. Therefore, we need a rather strong tinting (i.e., mixing of the icon/preview with the 'selection color') to make it obvious which folders are selected. (The reason why the tinting has been introduced at all is bug 295515.)

2. On the other hand, even a not-so-strong tinting with blue makes colors like red and green look very strange.

The attached example, where the tinting strength decreases from 1.0 (the current value) to 0.4 in steps of 0.1, shows that it quickly becomes harder to distinguish selected and non-selected blue icons. This effect is much stronger if the icon zoom level is lower.

I am now convinced that the entire tinting concept, even though it might have looked like an elegant way to resolve bug 295515, is severely broken and should ideally be replaced with something else in KDE 4.11. Maybe we can just draw a 'selection rectangle' around icon AND name, just like in Dolphin 1.x, and leave the color of the icon/preview itself unmodified.

A short-term compromise might be to reduce the tinting from 1.0 to 0.8. Selected photos still don't look beautiful then, but the most awful ugliness is gone then.
Comment 3 Frank Reininghaus 2013-01-11 16:21:50 UTC
Git commit 6083215645591a77b5e706b753650b8f3635a3b8 by Frank Reininghaus.
Committed on 11/01/2013 at 17:12.
Pushed by freininghaus into branch 'KDE/4.10'.

Slightly reduce the tinting for selected icons and previews

The intention of the tinting was to make it more obvious in icons view
which icons are selected. However, some icons and previews look quite
ugly with the current tinting value of 1.0 (i.e., the value passed to
KIconEffect::colorize). A slight reduction of this value to 0.8 makes
this a little less ugly. However, the real fix is to remove the tinting
altogether and find something better to indicate which items are

M  +1    -1    dolphin/src/kitemviews/kstandarditemlistwidget.cpp

Comment 4 Janet 2013-04-12 12:07:22 UTC
> Maybe we can just draw a 'selection rectangle' around icon AND name, just like in Dolphin 1.x, and leave the color of the icon/preview itself unmodified.

I'd really appreciate that, it just looks more elegant and the icon stays recognizable. The colors of an icon help to identify it, not just only the content and outline.
Comment 5 Frank Reininghaus 2013-09-23 11:33:34 UTC
*** Bug 325127 has been marked as a duplicate of this bug. ***
Comment 6 Frank Reininghaus 2013-11-07 16:32:10 UTC
Created attachment 83410 [details]
Removes tinting of icons and draws a selection rectangle around icon and text

I've been constantly busy with other things, but this issue really has been put off far too long now. Just the other day when I was going through folders with lots of pictures, I realized again just how ugly the tinting makes the previews.

I'll prepare some before/after screenshots and upload the patch to ReviewBoard during the next few days, such that others can have a look at it, and we can use it for Dolphin 4.12, which will be released next month.
Comment 7 Christoph Feck 2013-11-07 22:14:22 UTC
Frank, that's what I used locally, and what Peter originally used as the selection box (not only for rendering, but also for clicking).

Later it was noticed that placement of the "+" symbol should be relative to the icon/image, not the selection box, otherwise it causes inconsistency when trying to quickly select multiple files using the "+" symbol.

The patch you propose fixes the rendering, but introduces a new inconsistency between rendering and clicking rectangles. A solution to this would be an upside-down "T"-shaped selection marker, which unfortunately Qt or Qt styles do not provide, but we could use custom rendering. See http://pastebin.kde.org/pnb105pxi for an idea (which needs adjustments for the case where the text if shorter than the icon).

Additionally, I recommend to change it only after bug 299328 has been addressed, since otherwise the "+" symbols are even more prone to "hit and miss".

No need to respond here, but maybe you get some inspirations for the review request, where we can discuss further. Merci :)
Comment 8 Christoph Feck 2013-11-08 01:33:09 UTC
Created attachment 83418 [details]
Improved version of selection rendering
Comment 9 Christoph Feck 2013-11-08 01:34:08 UTC
Created attachment 83419 [details]
Produced example screenshot
Comment 10 Frank Reininghaus 2013-11-08 10:44:56 UTC
Thanks for your detailed response and your new ideas, Christoph! I wasn't aware that something like my patch from comment 6 had been used at some point - at that time, I wasn't following anything related to rendering much, because I was busy working on other things.

The mismatch between the rendered rectangle and the area that is sensitive to clicking is a valid concern that should better be addressed. Your idea to use a non-rectangular area looks like a good solution! However, could there be a risk that some people will find the non-rectangular shape, which is different for every item, odd and distracting? (Note that I'm not an expert for anything related to rendering/style/design though, so maybe these worries are not justified at all. In any case, I like your suggestion, and I think that there will be few people who will consider it worse than what we have at the moment.)

You're also right that it might be a godd idea to adress the selection-marker-hover issue first. I will probably not have much time to work on this during the next few days though.
Comment 11 Emmanuel Pescosta 2014-02-05 16:41:44 UTC
(In reply to comment #9)
> Created attachment 83419 [details]
> Produced example screenshot

Wow this looks really good! :D
Comment 12 Justin Zobel 2021-03-09 02:18:58 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.