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". Thanks. Reproducible: Always Steps to Reproduce: 1. Launch Dolphin 2. Select an item (any view mode) 3. Actual Results: Strong, monochrome tinting Expected Results: Moderate, more subdued tinting
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.
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.
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 selected. M +1 -1 dolphin/src/kitemviews/kstandarditemlistwidget.cpp http://commits.kde.org/kde-baseapps/6083215645591a77b5e706b753650b8f3635a3b8
> 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.
*** Bug 325127 has been marked as a duplicate of this bug. ***
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.
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 :)
Created attachment 83418 [details] Improved version of selection rendering
Created attachment 83419 [details] Produced example screenshot
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.
(In reply to comment #9) > Created attachment 83419 [details] > Produced example screenshot Wow this looks really good! :D
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.