Nemo: Option To Show Folder Sizes In List View

[InkKnife]

As found in the OSX Finder. The option to tell Nemo to calculate and display folder sizes in list view.

[ManIVIctorious]

+1

[gauravjuvekar]

This might cause severe performance issues. Please make it optional. Just imagine navigating in / using this option.

[anandrkris]

:+1: Am thinking how "optional" should get implemented - either as a Preference setting that applies across all folders opened or a quick toggle button to show folder size in Tool bar itself that can be enabled after the contents of the folder is loaded and Nemo can remember the previous setting for that folder. Having latter option of specific for folder will be beneficial, IMHO.

[InkKnife]

My experience on OSX is that, unless a directory has many, very large sub-directories the calculation does not slow things down much. I do agree that this should be an option and seems a check box in prefs that is global would be the easiest. Caching is a good idea.

[joelostblom]

This would be great. +1
Even cooler if we could add columns that would run a custom command on the selected file/folder and then display the result. Such as 'du -hs %s' or something similar for folder size.

[highwindmx]

+1 ,with a warning and a blacklist ,I think the user will learn to use this.

[InkKnife]

This feature would make Nemo unique. There is no other file manager on any Linux distro or even for Windows that provides this functionality. Bragging rights +++

[adamryczkowski]

I know the measurement is costly and imprecise. For cost I'd suggest that the calculation would be done on-demand only, triggered by a shortcut (or even by a button click).

Maybe a cleaner way to implement it is a new plug-in that populates on demand a custom column "deep size", that user can use a sort key.

See also
http://askubuntu.com/questions/298051/display-folder-sizes-in-file-manager
and
http://askubuntu.com/questions/101963/show-current-folder-size-in-nautilus

[InkKnife]

I am curious why this would be so costly. This is a feature I used comfortibly in the MacOS for twenty years and never found that it ever slowed my computer down. I should think if Apple could figure out how to do this economically it could be done here.

[ManIVIctorious]

Just tried a du -h on my root system with my 9 year old notebook, this took about 1minute, i think as long this is excluded on such places by default it wouldn't be that big of an performance issue

[InkKnife]

The way OSX handles it is that this is off by default and can be set in views on a folder by folder basis.

[adamryczkowski]

This stuff may be much more costly if the directory is a 10TB+ remote folder full of kernel sources... I think the only practical solution is demand-only, otherwise this functionality would effectively prevent nemo from browsing anything remote and big (like NAS shares over WiFi).

[azjio]

In the folder properties. Folder Size is calculated once and the user's request. Folder size is calculated when you click on the tab. In the folder tree to make a context menu to jump to a folder. Also in the context menu there is an item to delete the selected folder. Sorting by size. The size of the folder appears at the beginning of the name (For example, "[97 Gb] Name"). Symbolic links are not processed (For example, "[?] Name")
http://s018.radikal.ru/i520/1503/c5/e2e9bc0d6d09.png

[tp0]

This stuff may be much more costly if the directory is a 10TB+ remote folder full of kernel sources... I think the only practical solution is demand-only, otherwise this functionality would effectively prevent nemo from browsing anything remote and big (like NAS shares over WiFi).

Simple solution for that: calculate only local folders (just like Preferences > Preview > Show thumbnails > Always/Local files only).

[Vahan86]

@JosephMcc, can we mark this issue as a feature request?

[adotka]

+1. I miss this in Nemo forever

[mattmon]

+1

Doing the size calculation on the fly will be too slow.

Pretty sure that on both windows and mac this is implemented as a background service.

[nick-s-b]

So much this! This "9 Items" stuff in a size column is meaningless. It should display the actual size on disk and not this nonsensical "items" stuff.

@mattmon it takes less than a half a second for Nemo to calculate the size when I hit properties. Also, this can be cached.

[hipunk]

I also miss this feature a lot. It makes it much easier and also simpler to figure out what is what.

Making it optional would make everyone happy, I suppose.

[JosephMcc]

Many thanks for contributing to Nemo. Your suggestion was reviewed.

For more information on our workflow and feature requests, read https://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/faq.html.

[wimglenn]

Anywhere to see outcome of the review of a feature request? I read the FAQ linked, but it's not really clear whether resolution means "will not do" or "nice to have".

[alexanderdd]

@JosephMcc can you please specify which of these cases apply to this bug report:

When you submit an idea, it is processed and then closed. It might lead to an implementation, it might lead to a design discussion within the team, it might be planned for a particular release and put on the roadmap, it might lead to nothing at all, or it might stick in people’s minds as something they could improve later on.
(from https://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/faq.html)

[JosephMcc]

@alexanderdd I'm not really sure what answer you are looking for. The whole thing applies, That paragraph states pretty well how feature requests can be handled. This is clearly a request and not a bug report. It was marked as such and closed. That means anyone interested can still easily search for it and read what feedback people gave on the idea.

[alexanderdd]

@JosephMcc what is a good place for a meta discussion about how bug reports are handled in the linux mint project?

For this particular bug: For me a review includes a decision on how to continue with the issue. You said "Your suggestion was reviewed." I was expecting that you also specify which decision you made:

1. "will be implemented"
2. "will not be implemented"
3. "can be implemented if someone wants to do it"
4. "....."

Closing an issue implies that it has been fixed or there was a decision not to fix it/implement it.