Have window status line indicate used disk space

[BeOSR]

The bottom window status line could be extended to show the space the objects in the active window use on the disk next to their number. Make this a user setting via Tracker prefs. Of course symlinks would be excluded, as they are not part of the active window. Actually, as their object size is zero, it probably does not even matter.

Extended statusline example: 14 items | 3,06 Mb

[anevilyak]

That wouldn't necessarily be feasible since for directories for instance you'd have to recurse into them to calculate the size of everything they contain, which is potentially a quite time consuming op.

[humdinger]

Generally, I like the idea, though I see Rene's problem with it.

How about keeping just the number of items without filesizes and only update the items and their size when a selection is made. If you only select a few files, the updated info is instantaneous, if you include folders it unavoidably takes some time. As long as the system stays responsive and shows what it's doing by counting up the filesize, that's OK IMO.

[BeOSR]

The indicated size would be limited to the *active window only*, and not traverse (sub)directories. If you open a window, the size of any folder indicated as "-", just as it is for symlinks. These would be counted at that value, so zero. Only actual files or objects would be totaled.

This is not really relevant for system folders, but is very handy for user folders.

For an overview of used disk space per folder, DiskUsage works very well.

[BeOSR]

To be semantically correct, the status line would show the number of *files*, not *items*, and their cumulated disk space. As folders and symlinks aren't really files but placeholders, this should be clear.

Humdinger's point of showing the number of selected files and their total size is absolutely correct, so there'd be 2 views:

Basic view, nothing selected:
15 files | 5.4 Mb

With some files selected:
6 files selected | 1.2 Mb

Finally, it would be handy to have some indicator in the status line that parent folders can be browsed from that point, a lot of people don't know about this. Maybe use two dots to indicate parent directory or a dot and an up arrow or something? The very long horizontal scrollbar is a waste of space in most cases anyway.
^{. | 15 files | 5.4 Mb < [scrollbar] >
.. | 15 files selected | 5.4 Mb < [scrollbar] >}

[TigerKid001]

Hi! I'd like to work on this enhancement if its open. Any hints for getting started?

[pulkomandy]

I prefer having the number of items, rather than just the number of files, in the status bar. Anyway, this is displayed in src/kits/tracker/CountView.cpp, if you want to have a look at it.

[humdinger]

I still think this is a nice area to improve. So how about this:
Instead of e.g. "10 items", show the info separated in files and folders with the sum of the filesizes. No sizes for the folders, as recursing through them is problematic. For example: "folders: 2, files: 8 (238 KiB)"

Once you have some files/folders selected, only show the info of the selected files. We need some indication that the info now only applies to the selection. Maybe tinting the text background with the selection colour. Maybe simply using italics for the text.

[TigerKid001]

Status line enhancement to show number of folders, files and size

[TigerKid001]

The above patch makes the status line look like this:

| 7 items | 5 folders | 2 files (28.3 KiB) | < [scrollbar] >

Will add the selected items' info soon.. :)

[pulkomandy]

Hi, Some issues:

• You must leave two blank lines between methods GetCountsandSize and Draw
• GetCountAndSize should be named differently, because it doesn't "get" anything. Maybe UpdateCountAndSize ?
• The method could also be made private (and in this case its name should start with an underscore).
• entry.GetStat already gives you the stat info (StatStruct and struct stat are the same). You can get he file size from the st_size field in the struct, so there is no need for getting it from BFile.
• The method should probably initialize fDirCount, fFileCount, and fTotalFilesSize to 0 before the loop. Otherwise calling it multiple times will lead to the wrong results.
• If the model is not a directory, you will be using an uninitialized ref and tryng to get the list of files from it.
• You can use a BMessagFormat such as "{0, plural, one{# file} other{# files}} (%size%)", then use BString.ReplaceFirst to replace the "%size%" with the size. This will allow people working on localization to use a different format if needed (maybe they need [] instead of (), for example). It also makes it clearer to them how the string will be used.
• There seem to be a removal of a } in the patch that does not looks correct.

[TigerKid001]

Updated patch, fixed issues

[TigerKid001]

Hi, I've uploaded the corrected patch, with all above issues fixed.

[pulkomandy]

Hi, Now I see a few more problems:

if(fLastCount != fPoseView->CountItems()) 
    fLastCount = fPoseView->CountItems(); 

The if is useless.

if(model->IsDirectory()) 

Add a space between if and parentesis

off_t fileSize = 0; 

This variable is useless, you can do this:

fTotalFilesSize += statbuf.st_size; 

else 
 	        // we can't check for files and folders if model is not a directory
 	        return; 

Multiline else needs braces (even if it's a single statement, for our coding guidelines)

I think the call to dir.Rewind() is useless. When you create a BDirectory it is initialized to point at the start of the directory already.

Your error handling should be improved. If there is a file you can't stat, you are just exiting early, and the view will show the wrong numbers. You should at least replace the return with a continue to scan the remaining entries, and maybe add a warning message to the view in that case ("Some entries can't be identified" or something similar). But maybe the message would take too much space and it's better to ignore it.

[TigerKid001]

Updated patch, fixed more issues.

[pulkomandy]

Why did you make gMoreFiels a global? Can't it be a field of the class instead?

An even better solution would be to have only the string as a field of the class. This way, we can generate the string in _UpdateCount only once (or when the count changes), and drawing it does not need to recompute it each time the view is drawn.

[TigerKid001]

Added number of items selected

[TigerKid001]

Review ping :-)