Next Previous Table of Contents
You need to open a directory.
Either start the program with a directory parameter:
% kdirstat /work/home/kilroy
Or open a directory interactively with 'Open' from the 'File' menu.
Sure! Just drag an object from a KFM window to the KDirStat window. This will act just like the 'Add' command from the 'File' menu.
Probably the easiest and most comfortable way to start KDirStat is via KFM's context menu: Right-click on any directory in a KFM 'directory contents' window and select 'KDirStat'. The selected directory wil automatically be opened in KDirStat.
Open the 'Settings' dialog in the 'File' menu and select the 'Tree Colors' tab. Drag the slider at the right edge all the way up - now you have just one color left for all percentage bars. They will all be displayed in that color. Apply the settings with the 'OK' or the 'Apply' button. And don't forget to save your changes! (Select 'Save Settings' from the 'File' menu).
Nothing. They are just different to make it easier to see which directory belongs to which level - i.e. which bars make sense to compare to one another.
If you don't like that, you can change it (see above).
They are artificial entries that don't really exist. They are included within the tree to prevent cluttering up individual levels with a lot of objects. Usually you are more interested in a directory's subdirectories rather than its individual files - the subdirectories tend to use up more space than those files.
Plus, collecting all plain files in the <Files> pseudo entry clearly shows how much space all files of that directory level take in comparison to the subdirectories.
You can think of the <Files> entry as the '.' entry that every directory contains as a reference to itself (in fact, those pseudo entries internally are called 'Dot Entries' - see the KDirStat programmer's documentation for details). Only that those '.' entries hold just files, no subdirectories.
For directories that don't have subdirectories, a <Files> entry doesn't make too much sense - it just adds a level of complexity instead of reducing it. Thus directories that don't have subdirectories immediately display their individual files without that additional (artificial) <Files> level.
If you are using KDE standard colors, white is the default document background - i.e. the background color for most things the user can edit (input fields, lists, tables - and trees).
KDirStat does not honor this convention. For white (or black) backgrounds, KDirstat chooses some other color - a brighter version of the default widget background (the palette midlight color) for non-editable wigets (like push buttons).
This is to prevent ugly 3D effects which will inevitably be the case for a white (or black) background: The percentage bars use white and black for 3D borders - like any other widget. But other widgets normally can assume their parent widget uses some more neutral color so white and black will result in at least some minimal contrast.
Any document (palette base) color other than black or white will be honored normally. You might want to try this in the KDE control center: Select desktop / colors and then change the "window background" color.
For some time I planned to make this color user configurable in a settings dialog. But this would break compatibility with the KDE control center where users expect all applications to modify their appearance when they select different colors.
KDirStat's current behavious, however, complies with the KDE control center: KDirStat either uses the "window background" color selected there or (because this might be white - unfortunately the KDE default) a color based on the normal widget background. KDirStat will update its appearance accordingly along with the other KDE applications.
Unfortunately, you can't - right now, that is.
I would have liked very much to include that feature, but it wasn't possible without becoming incompatible to current KDE standards. Using KFM and the KDir object just doesn't provide that kind of information - the file system on which a file or directory resides is not being passed along.
Hopefully, this will change in the future. If it doesn't, I seriously consider reworking the internal engine to do 'lstat' system calls myself. This would break KDirStat's KFM integration and thus the multi-protocol capabilities. That would be too bad.
But I, too consider this an important feature. It will come. Promised. But it may take some time.
Just like plain files. Unfortunately. This is one other limitation of the KFM / KDir protocol I hope to overcome some day.
I chickened out on that one. I don't want anybody to flame me 'I accidentially deleted precious files with that dumb program of yours!'.
Just moving to the trash bin takes the responsibility out of my hands. The files are still there until you empty the trash bin. Thus, you'd have to make two mistakes to really do any harm.
If you want to have a true 'delete' cleanup, just add it as a custom cleanup. It's very simple. But don't blame me if you deleted something you'd rather have kept!
You may have an old setup file that contains cleanup actions with English titles. Check the following files:
$HOME/.kde/share/config/kdirstatrc your own configuration /opt/kde/share/config/kdirstatrc system wide configuration
You can:
With the first two of those options you will of course lose any of your KDirStat configuration changes.
I would have preferred to call the program 'kdu' to clearly point out the similarity to the unix 'du' command. But unfortunately, a program called 'kdu' existed before this one. So I had to give it some other name. And 'KDirStat' (for KDE Directory Statistics) was the best choice I came up with.
And no, I won't rename it. Even if somebody comes up with a really great name. That would mean too much hassle for everybody involved.
Next Previous Table of Contents