DE version is available. Content is displayed in original English for accuracy.
On containers or remote servers, the options are limited to purely text based utilities (e.g. du) or list-centric TUIs (e.g. ncdu) which are usually limited to viewing one directory at a time.
I created leaves to fill that gap.
Inspired by classic utilities like WinDirStat and KDirStat, it uses a 2-dimensional treemap^1 visualization to show the entire directory hierarchy with proportionally sized rectangles.
It's performant enough to handle millions of files, thanks to Rust and multi-threading. However, block characters aren't as suited as pixels for resolving a large number of items. Leaves can show file-type summaries per directory or partition the top-level directories by extension, allowing you to see not only where space is being used, but also how.
For instance, I can see the largest chunk of my home directory is taken up by uv caches for python and old Linux ISOs that I could easily re-download if needed. Or in a particular container, +600MB is used by standard Rust documentation and tutorials, and that it is the only location with HTML/JS files, when only the libraries and build tools are needed (note to self: remember to use the minimal profile next time).
^1: https://github.com/shundhammer/qdirstat/blob/master/doc/Tree...
Discussion (9 Comments)Read Original on HackerNews
What I really also want is a way to do an offline index that this reads ... I ended up using duc. Maybe I will fork and add it!
thanks for sharing!
I had been exploring using an embedded database as an index, but for my current use case, waiting just under a minute to rescan my /nix/store on a weak mini-pc is acceptable.
Also looking to add inotify integration, which would require an index to accurately update the visualization.
If possible, being able to “brew install” on a Mac would be killer
Can you provide some examples of "quick actions"?
Currently, the visualization is purely based on file sizes in the directory structure. Package management adds some complications beyond the fact that there are at least a dozen popular managers in the wild. For one, package dependencies form a directed graph rather than a hierarchical tree, so credit assignment is vague. Two packages can depend on the same two dependencies. Do we give full credit to both, one or assign partial credit? Would we weight partial credit evenly or by dependent size or some external factor/