Open paul-hammant opened 1 month ago
I discussed that in another issue some time ago (I can't find it right now; it wasn't #85).
The idea does have merit in general, but there are several unsolved problems:
QDirStat would have to determine if a directory has a dominant MIME type (file type) that has an associated color. While that's trivial if it only has one single MIME type, in most cases it's not so clear-cut: An MP3 directory, for example, tends to have some few files that are not MP3, but album cover art (.png or .jpg) or song texts (.txt). So there would have to be thresholds from which percent on a directory is being considered as dominated by one MIME type.
Just the sheer number of files is one metric, but what if there are a bunch of small files of one type, and a single large one of another type? Does a large MP4 video outweigh 47 tinyJPGs in a directory?
As treemap tiles get smaller in a huge directory tree, even whole subtrees may start disappearing. How would a dominant MIME type in a whole subtree be determined? How would that work with one MP4 video directory vs. several JPG directories, and how would that work out depending on which is larger in size overall? 47% accumulated MP4s vs. 53% accumulated JPGs, or the other way round?
In general, the higher up the hierarchy this gets, the more fuzzy the whole concept becomes.
Right now, directories are displayed with a blueish-grey diagonal gradient if their child tiles become too small to display, so the user can clearly tell the difference between a directory with "lots of little stuff" and a larger tile representing an individual file. But when directories also inherit a color from their dominant MIME type, they can easily be confused with one large file of that same MIME type.
I recall that back when that other issue was discussed, I did some experiments, and even a diagonal gradient with that same MIME color was really hard to distinguish from an individual file with the usual treemap cushion rendering. And that would be a big step backwards in terms of usability.
BTW you can already experiment with
[Treemaps]
...
MinTileSize=1
...
in ~/.config/QDirStat/QDirStat.conf
. The default is 3, but 1 gets you some less grey at the cost of rendering performance.
Related:
I'm a little bit out of touch with the master QDirStat code, but is this happening because all the file tiles are (relatively) very small so that they're all below the 3-pixel limit?
My latest tiling algorithm renders the whole directory space with coloured file tiles regardless of the minTileSize, but never got merged. It "accumulates" small files until it has something that renders at minTileSize, then drops tiles until it accumulates enough for another tile, so the entire available space in each parent tile is filled even if the tiniest tiles are really just showing a bit of a random selection of the smallest files. So the only things that come out plain grey are empty directories and they are almost always small enough to become invisible in the treemap. Performance is better than the current code despite this. Running at minTileSize is acceptably fast although it doesn't look much different, the smallest tiles tend to just blend together because a 1x1 tile can't really be shaded.
Here's a portion of my ~/.cache which may be comparable with your tree. It shows Firefox cache (in white, the default for files with no extension, different to the directory grey) and thumbnails in blue.
Dir is gray in the QDirStat depiction. It has child files that are 99.9% .PNG suffixed and 1% .TXT suffixed.
Could the directory's color be the same as the color of a tile for a .PNG suffixed file?
I appreciate the #85 discussed this before and files without suffixes are left as grey for good performance reasons - reading their contents would be costly vs making decisions based on their name only.