@Chris: “Expand the main widget”

The point is that almost everything (that is, everything apart from the edit box and scrollbars) in L is the *same* widget called ExtenderButton and its private subclass ActionListItem which adds DnD support.

So, all list items in all lists and everything else is essentially the same widget.

All models have the same API.

Now, introducing another method to the model and a feature for the ExtenderButtton/ActionListItem for the sole purpose of having a bar below the text (which would replace the mount path, which IMO is more important) in *one* model is a bit overkill, don’t you think?

Ok, so, the best pro-bar reason I’ve heard till now is ‘other kde apps do it’. You’ll have to beat that one

If you add a “fill state” to the model that represents the percentage of how much a disk is filled (0-100%) it would be perfectly fine to extend the main widget (showing only icon and name / path) by some other ones adding the specialized “fill state representation” logic (e.g. your current circle, vertical bars on the left, horizontal bars bellow the name / path and so on).

That way you would still have a clean model view separation with the possibility to use whatever visualization you want. What’s the problem you see with this way?

Further I have to admit I didn’t get the way your current circles represent the fill state either (starting at 3 o’clock and going counter clock wise) until I read the comments here ;D.

Last but not least I think that bars are perfectly fine to represent a fill state since we are already used it on computers (e.g. from other file managers) as well as in real life (e.g. an half full / empty bottle).

So it is basically a matter of taste about which one shouldn’t argue ;D (and my above suggestion would allow everyone to get what one prefers while keeping the model cleanly separated from the view).

Could you therefore please reconsider this or explain why you don’t like this suggestion so I perhaps can convince you? ;D

And the pie even takes big chunk away from the icons. And different colors are bad for space status because new/avarage user does not know what creen, yellow, red, blue etc colors mean.

But there is some problems with Dolphin way as well. That the space bar is shown only when hovering over the device or it is selected. (but I got answer that is technical problem not to query all the times the disk space and waking up the disks from sleep etc).
Thats why I am littlebit questioning this pie even more.

Great work!

Sorry for my bad english

Well, the article you linked says exactly what I am speaking of, even when the author is biased.

“Pie charts are not without their strengths. The primary strength of a pie chart is the fact that the message “part-to-whole relationship” is built right into it in an obvious way.”

It goes on further to say:

“A bar graph doesn’t have this obvious purpose built into its design. Not as directly, anyway, but it can be built into bar graphs in a way that prompts people to think in terms of a whole and its parts. This can be accomplished in part by using a percentage scale. It is easy and natural to think in terms of various percentages in relation to…”

I don’t have the space to make *any* scales in bars. Or anything similar.

The reason why they are so based, was first studied by William S. Cleveland, and as a mathematician, I am sure you’ll appreciate his interesting original 1984 paper:

Graphical Perception: Theory, Experimentation, and Application to the Development of Graphical Methods
Author(s): William S. Cleveland and Robert McGill
Source: Journal of the American Statistical Association, Vol. 79, No. 387 (Sep., 1984), pp. 531-554
Published by: American Statistical Association
Stable URL: http://www.jstor.org/stable/2288400

For information specfically on problems with pie charts, the article ‘Save the Pies for Dessert’ by Stephen Few has a thorough discussion and several examples:
http://www.perceptualedge.com/articles/08-21-07.pdf

Personally (and as a statistician) I have severe problems reading the pie charts in your screenshots. I’m still not quite sure which parts represent the used and the empty space. (OK, after reading the stuff about colour, I understand which parts represent what, but I still don’t perceive this when looking at the charts, and the use of blue as a colour makes the colour-coding even more unusual.)

The above problems disappear when using a well-designed (horizontal or vertical) bar, where the empty (transparent) parts represents the empty space, and the filled part (starting from the left or the bottom) represents the filled/used space. (If you’re just using two different colours on the bar, part of the perception problem reappears; it must be an empty colour and a fill colour. The fill colour can be colour-coded, from green through yellow to red.)

@Shyru: Finally a valid analogy for a bar. Still, it doesn’t really convince me that bars are better. I’ll ask Seele what she thinks.

@Emil Sedgh: Yes, it is in the trunk – has been since my last blog post.

As for the sections, I’ll probably make the order (thus allowing the change in the default shown item) customizable for 4.5 – like Favourites (amongst other parts) are.