Bug 295515

Summary: Dolphin file/folder selection doesn't provide enough highlight in KDE 4.8.1
Product: [Applications] dolphin Reporter: Simonas <obuolis1>
Component: view-engine: generalAssignee: Dolphin Bug Assignee <dolphin-bugs-null>
Status: RESOLVED FIXED    
Severity: wishlist CC: mihaiivaniuc, nate, swjawa
Priority: NOR    
Version: 2.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In: 4.9.0
Sentry Crash Report:
Attachments: Shows the indistinguishability of selected items from normal ones when only their icon is visible

Description Simonas 2012-03-08 09:45:14 UTC
In recent KDE 4.8.1, when you select file/folder in dolphin icon view mode, it only highlights the name of the file/folder, while it doesn't highlight the icon. That doesnt provide enough contrast to what icons you have selected because you no longer select the icons, but just the name of it. This could be also confusing for some, because the name is seperated from icon. This perhaps looks a bit cleaner than previously (4.8.0), but functionality i think is more important than clean look. In my opinion, the Dolphin 1.x icon selection looked way better, because highlight isn't seperated to text and icon so it looks consistent, but that's just my opinion.
In comparison, GNOME, Windows and OS X has icon highlight too when you select file/folder.
In any ways, if it's not valid, i would like to hear the reasons behind this change, for curiousity :)
Comment 1 Peter Penz 2012-04-12 19:34:10 UTC
*** Bug 297988 has been marked as a duplicate of this bug. ***
Comment 2 Peter Penz 2012-05-21 20:42:22 UTC
Git commit 1bcd7c557413cf5a4fa56bc547349468c3f91d72 by Peter Penz.
Committed on 21/05/2012 at 22:40.
Pushed by ppenz into branch 'master'.

Colorize icons when an item is selected
FIXED-IN: 4.9.0

M  +11   -13   dolphin/src/kitemviews/kstandarditemlistwidget.cpp
M  +0    -2    dolphin/src/kitemviews/kstandarditemlistwidget.h

http://commits.kde.org/kde-baseapps/1bcd7c557413cf5a4fa56bc547349468c3f91d72
Comment 3 Simonas 2012-05-22 07:40:07 UTC
Thanks for fix! :)
Would like to see screenshot, but i guess ill wait for 4.9 beta and see it myself.
Comment 4 Simonas 2012-06-14 08:22:39 UTC
Sorry to say this but the selection highlight is not what i wanted. It actually makes the interface even more weird looking, because it colors certain areas of icons, and still it doesnt give enough feedback. I think it would look better like on this old screenshot:
http://www.gnomejournal.org/images/r1-mime-nautilus.png
But im not sure if its possible, so i guess the old 4.8.0 behaviour was better.
Comment 5 Peter Penz 2012-06-14 14:22:14 UTC
I'm confused: Dolphin now uses the same approach as in your screenshot, the only difference is that Dolphin uses a blue color (= default selection color). You can of course change this color to grey.
Comment 6 Harold 2012-06-14 15:48:21 UTC
(In reply to comment #4)
> Sorry to say this but the selection highlight is not what i wanted. It
> actually makes the interface even more weird looking, because it colors
> certain areas of icons, and still it doesnt give enough feedback. I think it
> would look better like on this old screenshot:
> http://www.gnomejournal.org/images/r1-mime-nautilus.png
> But im not sure if its possible, so i guess the old 4.8.0 behaviour was
> better.

I disagree. The previous way of highlighting made it easier to see which and how many items are selected. The way it's done now makes the text look detached from the icon and it's almost confusing when a large number of items is selected.
In terms of weirdness, I think, that the current highlighting method is slightly greater, as the highlighted icon changes the way it looks. The colored background behind the icon and text, the way it was done before, acted as one would expect. Only the transparent areas of icons were colored.
Comment 7 Harold 2012-06-14 22:50:58 UTC
Created attachment 71846 [details]
Shows the indistinguishability of selected items from normal ones when only their icon is visible

I have discovered another flaw in this new highlighting style. When the window is not big enough for the bottom line of items to be displayed fully in the Icons view mode and only the icon is visible, there is no way to see if the item is selected or not.
I have attached a screenshot with the bottom row encircled. The left three items in the bottom row were selected and the right three were not. Yet there is no way to differentiate.

I suggest returning to the previous highlighting style.
Comment 8 Peter Penz 2012-06-14 23:28:26 UTC
@Peter: You've attached a screenshot from 4.8.x, but the fix from comment 2 is applied to 4.9 and does not have this problem.
Comment 9 Simonas 2012-06-15 07:35:45 UTC
@Peter Penz
Well the idea of highlighting is the same, but that blue highlight isnt enough, it doesnt color all the colors, e.g. mimetypes white paper area isnt blue (at least not enough). Take for example pdf icon, select it, the red parts of the icon becomes blue, but the white paper itself doesnt change the color that much. Altough when you actually select multiple files it still does help more than it is on 4.8.1 and later. I think that new highlight is better than in 4.8.1 and later, but still not as good as it was on 4.8.0 or earlier.

@Peter
By saying previous i meant 4.8.0 look, which had something similair to the kde 4.7 and previous releases look.
Comment 10 Peter Penz 2012-06-15 08:44:25 UTC
@Simons: I understand. I'll try to improve the "tinting"-code so that also white areas get blue.
Comment 11 Peter Penz 2012-06-15 09:03:27 UTC
Hm, fixing the tinting code is not as trivial as I thought. I'll wait for further feedback until 2.1 is out to collect more feedback - I intend to improve this but currently there are still more important issues to fix for 2.1 so it might take some time.
Comment 12 Simonas 2012-06-15 10:17:34 UTC
Thats what i imagined, because i didnt see anywhere in kde this tinting, so i understand that it could be difficult. Anyway like you said, thats not that important, and 2.1 tinting will still be better than it is now.
So thanks for all this work!
Comment 13 Jeroen van Meeuwen (Kolab Systems) 2012-08-24 16:21:31 UTC
Resetting assignee to default as per bug #305719
Comment 14 Nate Graham 2017-09-04 02:04:22 UTC
This is no longer an issue, both because the tinting code is better now, but also because the more recent Breeze icon theme inherently doesn't have this problem compared to the Oxygen theme that was visible when this bug was filed.