Version: (using KDE 4.0.1) Installed from: Unspecified I think it's better to show the size of folder in the "size" column. Maybe 'x Mb, y items' is a proper format.
I agree this would be better, but it's technically not possible as this would mean parsing all sub directories which could take several minutes :-( I'm not sure if Nepomuk will contain such kind of meta data too, so maybe this can be implemented in later KDE releases.
I'm very happy that you agree with me ;) I think we could give the parsing the lowest priority. At last, you could provide the options whether enable this feature or not. Sorry my English is not very good....:( But users all over the word all appreciate your Great Work.
> I think we could give the parsing the lowest priority. Yes, if we forward this task to Nepomuk/Strigi it is anyway done in background. > But users all over the word all appreciate your Great Work. Thanks, thats nice to hear and not very common to read in bug reports ;-)
hi there i would like to see this feature too. i think "on demand folder size" would be cool. not alway display folder sizes. this would consume too much resources. rather, like a button on the toolbar, that allow to "show selected folder sizes". this way it won't consume any resources and be applied only when user request it. this is useful when cleaning harddrive from old stuffs .. moving things around and etc.. instead of having to right click > select properties just a click on the toolbar would reveal selected folder sizes. tnx
*** Bug 44522 has been marked as a duplicate of this bug. ***
It turns out that Windows reports this information in a mouseover popup. The information comes up instantly, even for very large, very recursive directories. It does not seem to be calculated on the fly (due to it's speed), but it works for even newly-created directory trees. Screenshot of the Windows feature: http://bugsfiles.kde.org/attachment.cgi?id=30732
The button on the toolbar (or an option in the settings) is a good idea, you could choose when you want it on/off. I don't quite understand how the different FS work, but I've noticed it that sometimes this information takes no time (as if its static), other times I have to wait up to 10 seconds. I think it would be a good idea to have a spawned thread doing this task and that information being updated on the fly as it finishes getting the size for each child directory. And if the tab is closed before it finishes the thread should be killed. I don't see the need to use nepomuk on this. Besides, what about directories not being scanned by nepomuk? Let's not fall into the same problem as the image thumbnails issue. And while we're at it, having this information would allow it to give even more detailed info in the bottom bar for free! Currently we have: 2 Folders, 8 Files (4.3 MiB) But we could have: 10 items (3.2 GiB): 2 folders, 8 files (4.3 MiB)
I agree that this information would be useful to calculate in the background and then displayed as it becomes available, just as with image thumbnails. However, it should definitely be given lowest CPU and I/O priority (equivalent to using ionice -c3 on the command line).
A bit related to bug 275236. But it still doesn't do a recursive directory count, just the number of items in the directory's root.
(In reply to comment #6) > It turns out that Windows reports this information in a mouseover popup. The > information comes up instantly, even for very large, very recursive > directories. It does not seem to be calculated on the fly (due to it's speed), > but it works for even newly-created directory trees. > > Screenshot of the Windows feature: > http://bugsfiles.kde.org/attachment.cgi?id=30732 On Windows it's not instant, it depends on how much Files(items amount but without folders) it has. You can test with a folder with a lot of files, it will take a while until it will pop-up the information. And what Windows actually does: it calculates the files size but not recursively. For example, in a folder you have: 2 Folders, each one having 100 GB and 1 .txt file that is for example 3 KB. Windows will show you that the dimension of the folder is 3 KB. And I actually think that this is the correct way to do it considering that you don't want to impact the performance. It shows you the dimension of the files you will see if you enter in there, but there sure can be other folders which you can take a look at the dimension in the same way. It's not perfect but it is okay.
That's what I remember when I used Windows.
*** Bug 302998 has been marked as a duplicate of this bug. ***
Resetting assignee to default as per bug #305719
it's now 2017. I have a machine with an NVMe SSD, and calculating folder size is instantaneous enough that when the properties window has on-disk size available instantly. It doesn't seem like it would be any great burden to simple cache this information and make it available to Dolphin.
> calculating folder size is instantaneous ... but pollutes kernel caches with data that you may not need. > simple cache this information Cache where? How to decide if the information in the cache is still valid? If it was simple, the Linux kernel would provide this information.
Right, I understand the trade-offs involved. Personally I'm willing to accept those trade-offs, but obviously not everyone would. In the macOS Finder, turning on this feature is optional, probably for the same reasons. It could be similarly optional here, too. Turn it on if you like it, don't if you don't.
*** Bug 381508 has been marked as a duplicate of this bug. ***
Created attachment 108377 [details] Dolphin patch to add the setting I've tried to patch this in, and it's not hard; mostly a matter of having KFileItems representing folders calculate sizes uwing KIO::DirectorySizeJob. On a modern SSD, it's even fast enough to only be slightly annoying when doing it on the same thread. The following issues/challenges arise: - Need to do it on a background thread to avoid blocking the main UI - With the information panel open, moving the mouse spawns zillions of jobs since it updates according to cursor hover position, not selection - Should probably cache results, but how without keeping around old results that *should* be recalculated? - Need to figure out a way to make this optional without violating boundaries (e.g. should baloo depend on being able to parse a setting from Dolphin?) I'm attaching the rough patches in case someone with much more skill here wants to run with them and refine the feature to actually be usable.
Created attachment 108378 [details] Crude baloo-widgets patch to be able to calculate directory sizes
For comparison Directory Opus does it like this: 1. Calculation on hovering, cancelled when mouse leaves. 2. Toolbar button calculates size of all selected folders (in foreground, progress bar shown if taking a while). 3. Config option to enable automatic calculation. I think 2 & 3 together is a good solution. This means that it doesn't slow things down by default, but users with fast storage can turn the option on. I don't think there's a need for caching. Leaving it on manual mode, users wouldn't expect it to re-calculate automatically (the wording of the action should portray it so). And if on automatic mode, users could press F5 to re-calculate (I think F5=Refresh is something we can assume users know).
Git commit e6ea3ab4c41dcc115143a237aafd3a1152849433 by Méven Car. Committed on 04/05/2020 at 05:26. Pushed by meven into branch 'master'. [Details mode] Allow to fill the column size of directories with actual size Summary: Allow to compute the recursive size of directories to fill the details view size column. A setting allow to set a limit to the recursive level, allowing the user to have some power over the setting. When sorting by size and the feature is on, we get progressive ordering as the directory size are gathered. KDirectoryContentsCounter uses a cache internally to keep results so that it can display directory size faster, but counts the dir size of directories each time it is asked to count the size a directory nevertheless and when the size has changed, it is updated. KDirectoryContentsCounter uses one worker per instance only, meaning one process per view makes the disk spin. FIXED-IN: 20.08 Related: bug 190580 Test Plan: With some recursion allowed: {F8267580} Without any recursion allowed (default): {F8267581} Reviewers: elvisangelaccio, ngraham, #dolphin Reviewed By: elvisangelaccio, ngraham, #dolphin Subscribers: feverfew, anthonyfieroni, iasensio, kfm-devel Tags: #dolphin Differential Revision: https://phabricator.kde.org/D25335 M +8 -0 src/dolphinviewcontainer.cpp M +16 -4 src/kitemviews/kfileitemlistwidget.cpp M +15 -3 src/kitemviews/kfileitemmodel.cpp M +9 -11 src/kitemviews/kfileitemmodelrolesupdater.cpp M +1 -1 src/kitemviews/kfileitemmodelrolesupdater.h M +39 -32 src/kitemviews/private/kdirectorycontentscounter.cpp M +8 -13 src/kitemviews/private/kdirectorycontentscounter.h M +68 -30 src/kitemviews/private/kdirectorycontentscounterworker.cpp M +11 -3 src/kitemviews/private/kdirectorycontentscounterworker.h M +8 -0 src/settings/dolphin_detailsmodesettings.kcfg M +45 -5 src/settings/viewmodes/viewsettingstab.cpp M +5 -0 src/settings/viewmodes/viewsettingstab.h https://commits.kde.org/dolphin/e6ea3ab4c41dcc115143a237aafd3a1152849433
*** Bug 421729 has been marked as a duplicate of this bug. ***