Add size on disk for folders in UI

[UvuvDev]

What is the feature you'd like to have?
In the UI right now, I have to add up the sizes of all the files myself, which when working with large firmware images that have nested extractions or filesystems, makes it very hard to tell what is what. Being able to see whether a folder is 10 gigs or 64 bytes would be great UX wise.

Is your feature request related to a problem?
No.

Are any alternative solutions acceptable?
Not really.

Additional Information:
What the UI does right now.

[zznop]

To determine the total size of the files contained in a folder you would need to walk the tree. This is why folder sizes aren't displayed in Finder or with ls either. Not saying that a du style report wouldn't be useful to determine total sizes of files contained in folders, but keeping track of a "folder size" in projects doesn't seem worth it.

[UvuvDev]

I think the performance implications of walking the tree are not that excessive. Running du -h on my filesystem takes me 29 seconds to get through 455 Gigs of data. I think the convenience outweighs that cost for most users. It should be disableable in settings though. Since du does not directly translate to Binary Ninja's performance I would like to implement this first and then benchmark performance to see if it should be merged.

[fuzyll]

Is the actual usability problem here "I can't see total folder size", or is the usability problem "I have a bunch of similarly named folders and they're cut off because we display as a table and the default behavior of that table in Qt is not great for this specific UI"?

Like, shouldn't the primary way users "tell what is what" be from user-controllable data like file or folder name and not "size of data within folder"?

I am really worried we're going to wind up implementing a performance problem instead of tackling the real usability issue. But, if we genuinely need folder size for a particular workflow, I'm not completely opposed as long as it's not on by default. Walking the tree might be fine under normal circumstances with a fast disk, but once you try to do this on a system under load with a slower disk, this will be awful.

[zznop]

du -h taking "29 seconds through 455 Gigs of data" isn't comforting when we need to display the directory tree instantly in the projects UI. Even a second of latency would make for a bad experience. This would especially be an issue when we start implementing features like #8301 and are importing entire ext4 file systems into projects and we have multiple layers of nested sub-directories with many files. I think for similar reasons, this is why this information isn't shown in Windows Explorer or Finder either.

[UvuvDev]

Is the actual usability problem here "I can't see total folder size", or is the usability problem "I have a bunch of similarly named folders and they're cut off because we display as a table and the default behavior of that table in Qt is not great for this specific UI"?

The former: when importing things with a ton of sub folders (ex. a firmware image) I find it very difficult to parse if I don't already know the directory structure. Part of the reason it had 11 folders was the way my code was set up but I have been annoyed by it before elsewhere with even 1 or 2 directories. For my workflow I just tend to have a lot of folders with basically no value that are just random headers, and then the actual file I care about which is 200MB. The names are not originally cut off in the table I just had it like that for a test.

I am really worried we're going to wind up implementing a performance problem instead of tackling the real usability issue. But, if we genuinely need folder size for a particular workflow, I'm not completely opposed as long as it's not on by default.

Sounds good to me, I'm fine with it not being on by default.

[plafosse]

FWIW Google Drive doesn't even show you the size of a folder

[fuzyll]

For my workflow I just tend to have a lot of folders with basically no value that are just random headers, and then the actual file I care about which is 200MB.

Out of curiosity, why does the file type not help with this? I still think I'm not quite understanding if we need folder size or if the stuff that's already there is just not being displayed in a way that's useful.

A button or something that's just like "display folder sizes" that kicks off the background calculation is fine if we really need the sizes, I'm just still stuck on trying to understand if file size is actually the requirement.

I just want to avoid us implementing a "hang the program" action if someone misclicks or doesn't understand the implications. It's also an extra thing to maintain. But, if we need it, we need it.

[UvuvDev]

Out of curiosity, why does the file type not help with this?

File type requires everything expanded, which there seems to be no option for. Otherwise everything is just folders

I feel like adding an expand all is something we should do anyways and would mostly fix this problem. Would require some scrolling but in my opinion that's fine

[psifertex]

This is an anti-feature. The work required is not worth the benefit. (the folder file size that is, it's specifically a technical trap. Seems fine but has too many potential issues for small gain)

Expand-all is probably fine though? Less fraught anyway.

[negasora]

You could also switch to table view if you want to see all the files but I'm not opposed to an expand/collapse all