|Summary:||[patch] Usability improvement for list view|
|Product:||kdelibs||Reporter:||Alex Radu <AlexRadu01>|
|Component:||general||Assignee:||Martin Koller <kollix>|
|Latest Commit:||Version Fixed In:|
Illustration fo al the improvements I want for Konqueror's list view
Snapshot of above patch in action
Updated Patch for kdelibs
Patch for kdebase
Description Alex Radu 2003-06-15 04:33:05 UTC
Version: 3.1.2 (using KDE KDE 3.1.2) Installed from: SuSE RPMs OS: Linux 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.
Comment 1 Alex Radu 2003-06-15 04:34:27 UTC
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 mentioned
Comment 2 Alex Radu 2003-08-13 03:30:31 UTC
And here are some more look and feel enchancement suggestions for KDE: http://bugs.kde.org/show_bug.cgi?id=58944 http://bugs.kde.org/show_bug.cgi?id=59791 http://bugs.kde.org/show_bug.cgi?id=62577
Comment 3 Christian Loose 2003-11-05 10:15:17 UTC
This sound more like a wish for a change in KListView, so I changed the product to kdelibs.
Comment 4 Paul Sprakes 2004-07-24 15:26:03 UTC
Created attachment 6818 [details] Proposed patch 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.
Comment 5 Paul Sprakes 2004-07-24 15:29:43 UTC
Created attachment 6819 [details] Snapshot of above patch in action
Comment 6 Sander Devrieze 2004-07-24 15:54:42 UTC
I think it's a little bit too light: especially people with bad eyes will have trouble.
Comment 7 Alex Radu 2004-07-24 21:33:58 UTC
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.
Comment 8 cerebro84 2004-07-25 12:52:39 UTC
Yes, a little bit darker please, it's almost perfect
Comment 9 Paul Sprakes 2004-07-25 14:55:30 UTC
Created attachment 6835 [details] example 2 Is this one better?
Comment 10 cerebro84 2004-07-25 16:49:07 UTC
Yes, it's better.
Comment 11 Jorge Adriano 2004-07-25 17:37:03 UTC
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!
Comment 12 Alex Radu 2004-07-26 07:53:25 UTC
Now I think "perfect" would sum up the way I feel about it :)
Comment 13 Paul Sprakes 2004-07-26 11:53:50 UTC
Created attachment 6850 [details] Updated patch With darker shade colour.
Comment 14 Andrew Somerville 2004-07-27 23:55:18 UTC
I think a little darker would be good too. Can't go wrong.
Comment 15 Alex Radu 2004-07-28 09:08:41 UTC
Should I close this now?
Comment 16 Paul Sprakes 2004-07-28 10:42:15 UTC
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.
Comment 17 Paul Sprakes 2004-09-03 14:07:10 UTC
Any chance this patch can go in now?
Comment 18 Scott Wheeler 2004-09-03 15:35:03 UTC
I'll give it a whirl this weekend. I'll really have to see how it "feels" before committing something of the sort.
Comment 19 cerebro84 2004-09-03 16:09:44 UTC
I've been using it for a while (by when the patch has appeared here) and I think it's very beautiful and useful
Comment 20 Paul Sprakes 2004-09-03 16:20:25 UTC
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.
Comment 21 Paul Sprakes 2004-09-28 15:11:29 UTC
Scott: Any luck?
Comment 22 Alex Radu 2004-11-01 02:27:34 UTC
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".
Comment 23 cerebro84 2004-11-01 20:16:23 UTC
I like it very much, it's not only eye-candy, but also very beautiful
Comment 24 cerebro84 2004-11-01 20:30:34 UTC
beautiful = useful. Why don't you make it as an option?
Comment 25 Christoph Wiesen 2004-11-02 14:06:39 UTC
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.
Comment 26 Martin Koller 2004-12-05 01:24:04 UTC
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.
Comment 27 Paul Sprakes 2004-12-05 02:01:18 UTC
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.
Comment 28 Paul Sprakes 2004-12-07 01:41:30 UTC
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. e.g: [General] listViewSortColVFactor=-10 Possible values are -100 to 100 where -100 is 100% darker and 100 is 100% lighter.
Comment 29 Paul Sprakes 2004-12-07 01:44:23 UTC
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.
Comment 30 Christoph Wiesen 2004-12-07 20:37:57 UTC
> 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.
Comment 31 Martin Koller 2004-12-07 20:45:28 UTC
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 shading.
Comment 32 Christoph Wiesen 2004-12-07 21:10:45 UTC
> > 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.
Comment 33 Martin Koller 2004-12-08 17:06:40 UTC
CVS commit by mkoller: FEATURE: 59791 GUI: 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
Comment 34 Alex Radu 2005-01-18 02:08:30 UTC
Does this mean it will be default for KDE 3.4? *Crosses fingers anxiously*
Comment 35 Martin Koller 2005-01-18 08:52:44 UTC
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.
Comment 36 Alex Radu 2005-01-18 09:00:58 UTC
That's good. But do we really need MORE options in Kcontrol....?
Comment 37 Alex Radu 2005-01-18 09:01:43 UTC
Why would anyone not want this? :p
Comment 38 Martin Koller 2005-01-18 09:50:16 UTC
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.
Comment 39 John Tapsell 2005-03-01 10:35:31 UTC
I think you should ask the person who changed the default why they did so. This should not be configurable in kcontrol.
Comment 40 Jason W 2005-03-02 20:25:55 UTC
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 :)