Version: 3.1.2 (using KDE KDE 3.1.2)
Installed from: SuSE RPMs
In GNOME's Nautilus, Microsoft's Explorer and Apple's Finder when in the detailed list view if the header of a column is clicked to order by the criteria of that header up or down that column looks different from the rest of the columns. This distrinction makes it easier to find what you'r elooking for and distinguish the data of the column you want to look at from the rest. It also makes it easier to knw which column header was clicked
Another usability improvement very related is alternating light and gray rows like in Juk or nautilus and other file managers.
Please check out the screenshot to fully understand.
Created attachment 1808 [details]
Illustration fo al the improvements I want for Konqueror's list view
As you can see, Nautilus already has thes nice usability enchancements I
And here are some more look and feel enchancement suggestions for KDE:
This sound more like a wish for a change in KListView, so I changed the product to kdelibs.
Created attachment 6818 [details]
Attached patch slightly shades the currently sorted column. It adds a
shadeSortColumn property to KListView to turn it on and off (it's on by
default). Note that single column tables should probably turn it off.
Created attachment 6819 [details]
Snapshot of above patch in action
I think it's a little bit too light: especially people with bad eyes will have trouble.
I like it, but I have to agree, it is a bit too light. I think a 10% increase in darkness would be perfect.
Again, thanks for the patch.
Yes, a little bit darker please, it's almost perfect
Created attachment 6835 [details]
Is this one better?
Yes, it's better.
Much better :) I'd still prefer it a little darker, but I don't know about others... A few different screenshots and a pool would be cool :D
Thank you for the patches!
Now I think "perfect" would sum up the way I feel about it :)
Created attachment 6850 [details]
With darker shade colour.
I think a little darker would be good too. Can't go wrong.
Should I close this now?
No. If this patch is excepted it will be merged into the main KDE sources and then this bug will be closed. I don't think it will go im until after 3.3 is out.
Any chance this patch can go in now?
I'll give it a whirl this weekend. I'll really have to see how it "feels" before committing something of the sort.
I've been using it for a while (by when the patch has appeared here) and I think it's very beautiful and useful
Thanks. I'll just point out a couple of issues before you give it a try:
1. When the sort column has a tree view the background of the branch items isn't altered. This is also an issue for the alternating background colour too. I've looked into it and their doesn't seem to be an easy way around it.
2. I'd like to be abe to turn it on/off when in Konqueror (maybe from View->Configure Background). I'll wait and see if it goes in cvs before I do this though.
Scott: Any luck?
1. yes, this is a problem.
2. I think that this would be unnecessary and would heighten KDE's image as "feature bloated and cluttered".
I like it very much, it's not only eye-candy, but also very beautiful
beautiful = useful. Why don't you make it as an option?
Another vote for this in 3.4 - can't see why this should be optional though. Looking at the screenshots I don't think it's so disturbing (not at all of course) that it would get in the way of normal usage (when the 'name' column is highlighted - contrary it should be easier on the eyes to distinguish between 'name' and 'the rest' at a glance.
I'm not sure - is the way highlighting will work for tree view really a problem? Actually that's the view I use almost exclusively and I don't consider it as a problem that the alternating colour doesnt span across the branch items ("it's not a bug, it's a feature" :)) because the tree-view lines are more like an element of it's own. If you make real use of them (following the lines to see what belongs under what) they are more like an vertival element, you look at from top to bottom. If there are horizontal lines going from left to right everywhere through it I guess that would disturb 'normal use' of thebranch items. Therefor i don't think it's a problem that the new highlighting won't span across the branch items as well.
I looked at the patch and have seen that it does not completely work.
The shading color is not used when you select an item which is in a shaded (sorted) column.
This is due to the fact that currently konqueror draws its listview items itself, and does not know about the shading.
I'm currently working on a patch which solves those issues.
It used to work until konqueror changed the selection method. I updated my patch about a week ago so will upload it here later today.
Created attachment 8560 [details]
Updated Patch for kdelibs
Sorry for the delay - been busy.
This is patch 1 of 2 for kdelibs. It now uses a global setting for the shade
factor (defaults to zero). You'll need to edit ~/.kde/share/config/kdeglobals
and add the property listViewSortColVFactor to the [General] section.
Possible values are -100 to 100 where -100 is 100% darker and 100 is 100%
Created attachment 8561 [details]
Patch for kdebase
This is the second part of the patch for kdebase. It solves the problem with
Konqueror's new highlighting method.
> You'll need to edit ~/.kde/share/config/kdeglobals
So basically this won't be enabled by default in future KDE versions?
Not that it matters, but personally I think we'd need this improvement more than 'yet another choice' to be done by end users.
On Tuesday 07 December 2004 20:37, Christoph Wiesen wrote:
> So basically this won't be enabled by default in future KDE versions?
No. The plan is to enable it by default (and I do not plan to add a GUI option
to disable it). Disabling is therefore only available for C++ programmers who
have special needs if they want to use the KListView class but without the
> > So basically this won't be enabled by default in future KDE versions?
> No. The plan is to enable it by default (and I do not plan to add a GUI
> option to disable it). Disabling is therefore only available for C++
> programmers who have special needs if they want to use the KListView class
> but without the shading.
Oh, sorry then. I obviously misunderstood this. Thanks for clearing it up.
CVS commit by mkoller:
All items in the sorted column are drawn with a shaded background.
Based on a patch from Paul Sprakes.
M +53 -13 klistview.cpp 1.244
M +23 -3 klistview.h 1.128
Does this mean it will be default for KDE 3.4? *Crosses fingers anxiously*
Yes. With my latest commits it also got a GUI element to enable/disable it.
It's located in kcontrol/colors and is ON by default.
That's good. But do we really need MORE options in Kcontrol....?
Why would anyone not want this? :p
On Tuesday 18 January 2005 09:01, Alex Radu wrote:
> ------- Why would anyone not want this? :p
I was also thinking that way - until someone reverted the default to false.
So I implemented the GUI option to at least have the ability to have a "true"
as default, still giving the possibility to switch it off.
I think you should ask the person who changed the default why they did so.
This should not be configurable in kcontrol.
I for one wouldn't want my name column shaded all the time. The times when I sort by another column, I don't need those columns shaded either as I'm perfectly aware which headed I just clicked on. If I should forget, it's pretty quick to glance up at the headers and see which has an arrow (assuming I can't figure it out by looking at which column has it's data sorted).
It is IMHO useless visual clutter. Obviously others disagree. This lends itself to an option, be it in some 'advanced' tab, or only available through editing some RC file. The latter might be best, less extremely rarely used options in kcontrol, but still affording a possibility to turn off the shading for those who really want it.. So yeah, RC file param at the very least please :)