Allow color assignment by size rather than file type

[marsfan]

It would be nice for QDirStat to have an option to use file size rather than file type for determining the colors to use. This could allow the user to quickly visualize rough percentage of space taken up by a specific file type within the folder, rather than overall file categories.

For example, imagine a simple example where a color table of four colors were selected as such.

Rank	Color
1	Orange
2	Yellow
3	Green
Other	Gray

A directory would be scanned and it would be determined that space taken up by different file types is in the following order.

File Type
mov
mp4
m4v

| other types |

The software would then assign the colors in the same order as the file sizes. Therefore, the scan results for this folder would have the following color table.

File Type	Color
mov	Orange
mp4	Yellow
m4v	Green
other types	gray

However, a folder where more space is taken up by mp4 files rather than mov files will have the mp4 files show up in the treemap as orange, while the mov files will show up in yellow.

[shundhammer]

No. For individual files, the file size already corresponds to the area of each treemap tile.

The tile colors are supposed to give a hint about the file type - on the whole treemap, and statically. One big downside of WinDirStat is that it assigns the treemap colors in the way you suggest, but globally: The file type consuming most disk space gets color #1, the next one color #2 etc.; so you always need that "file type legend" sub-window to explain which is which. This is poor usability.

Adding insult to injury, if you see only a partial subtree, the meanings of those colors change completely. The classic example are the Windows swap and suspend files pagefile.sys and hiberfil.sys in the root directory of the C: drive: Those .sys files are almost always the file type that consume the most disk space, so they get color #1 (which is completely pointless since those two are also the largest blobs).

When you only scan, say, C:\Windows, those two large files are out of scope, so the next-larger file type that previously got color #2 now gets color #1.

The net result is that you can never make sense of such a treemap without studying the legend. That makes the whole treemap much less useful.

With the QDirStat / KDirStat treemap, however, each color has a fixed meaning, so I can see at a glance that my directory tree is dominated by JPGs or by MP3s.

This is important. It also makes much more efficient use of the users' learning curve: They only have to learn once what each color means. It's not ambiguous.

I also don't want hundreds of screenshots floating around the Internet made by bloggers / "reviewers" who can't be bothered to read the documentation (i.e. 99.8% of them), do random changes to the configuration and make the result look like QDirStat always has to look as bad as they chose in their configuration (it's bad enough that some of them discovered that ugly "treemap as side panel" thingy that somebody wanted to have so badly).

[shundhammer]

Also, imagine what would happen when zooming into the treemap (mouse wheel): As you zoom in, the order of total disk space used by a file type can easily change. But surely you wouldn't want to change colors for the file types as you zoom: That would throw you off your context even more than it already does. Just a moment ago you saw a big blue blob in that directory, and as you zoom in, it has now become a large yellow blob; is that still the same thing that you just saw? You'd be force to check the Details panel before and after, possibly zooming out again to compare, then zooming in again. Yikes.

Yet, sticking with one color scheme that would fit in with what you suggested would mean that it would have those semantics only when viewing the complete treemap for the scanned subtree; as you zoom in, it would become random.

For example, on my /work partition I have 61.7 GB worth of JPG images in /work/photos and 35.2 GB worth of videos in /work/video, so the first color (say, cyan) would be assigned to images and the second (say, magenta) to videos.

As I zoom the treemap (while still having all of /work scanned in memory) into /work/video, would the videos there still be magenta as before, or would they become cyan because they are now by far the dominating file type?

When drilling down by treemap zooming, would you really want to change colors on every step of the way, always assigning the first color to the dominating file type? If not, what point would it have to assign colors by total size used in the whole scanned directory tree; since that scheme would only be valid on the top level?

[shundhammer]

This is why QDirStat uses a static color scheme that does not force you to do mental acrobatics every time you see a treemap or with every operation on the treemap; or even when choosing what directory tree to scan.

You don't need to refer to a color legend every time; you can re-use your previously learned knowledge about what color means what file type.