Created attachment 147975 [details]
doodle

Mhhh. Well spotted.

@Nate I wonder what to do here. We kinda need to display something else entirely - we don' t know the size of /home/foo until it is scanned but scanning may take forever. Perhaps the best approach would be to not use this summary view at all and instead have a widget with a button? See attached doodle

I can actually reproduce a less severe version of this issue with the non-flatpak version too.

On the overview, it says my home folder (which is backed by a separate /home partition) has 221 GiB used. When I click on it and it performs the final calculation, it says 200 GiB.

So something is wonky here even outside of a sandboxed environment.

In terms of how we fix it, for the Flatpak case we could simply have it scan immediately on launch instead of showing you the overview page, which is somewhat pointless when it only has a single item on it.

But we should also figure out what's going on with the non-flatpak case. I wonder if it's getting the numbers for the overview page from a different data source such that the two will never be in sync and it is just unfixably broken.

> On the overview, it says my home folder (which is backed by a separate /home partition) has 221 GiB used. When I click on it and it performs the final calculation, it says 200 GiB.

That's expected. The size a partition reports isn't necessarily the space occupied by files (also the user isn't necessarily allowed to traverse them)

> In terms of how we fix it, for the Flatpak case we could simply have it scan immediately on launch instead of showing you the overview page, which is somewhat pointless when it only has a single item on it.

I've been pondering that but think it is a bit meh. The user doesn't know what's going on, all they've done is start an app. It's also discounting the possibility that the user might actually want to scan a specific directory, not the entire thing.

My counter offer would be the view I've proposed but with two buttons ;)

[Scan Home]  [Scan Directory]

^ starts scan on home
                          ^ opens dir dialog

> That's expected. The size a partition reports isn't necessarily the space occupied by files
> (also the user isn't necessarily allowed to traverse them)
Well, that's a major problem, and I'm somewhat surprised that it's only coming up now. Inaccurate numbers are inaccurate numbers. The entire concept of the overview page seems to be unfixably broken, at best pointless and at worst harmful (for giving you wrong numbers, causing trust in the app to be lost).

Your proposal to replace it with buttons is acceptable to me. Maybe add a third button, so we have three options on the overview when you launch the app:

[Scan entire system]
[Scan home holder]
[Scan specific folder...]

And then we can hide the [Scan entire system] button if the app detects that it can't see / or something.

(In reply to Nate Graham from comment #5)
> > That's expected. The size a partition reports isn't necessarily the space occupied by files
> > (also the user isn't necessarily allowed to traverse them)
> Well, that's a major problem, and I'm somewhat surprised that it's only
> coming up now. Inaccurate numbers are inaccurate numbers. The entire concept
> of the overview page seems to be unfixably broken, at best pointless and at
> worst harmful (for giving you wrong numbers, causing trust in the app to be
> lost).
> 
> Your proposal to replace it with buttons is acceptable to me. Maybe add a
> third button, so we have three options on the overview when you launch the
> app:
> 
> [Scan entire system]
> [Scan home holder]
> [Scan specific folder...]
> 
> And then we can hide the [Scan entire system] button if the app detects that
> it can't see / or something.

The idea of the overview page is for the user to quickly be able to scan an entire drive, I think. I must admit that I too don't have much love for it.

Git commit 38a71d1cbd46964f47eac1377788ebaabc5956d8 by Harald Sitter.
Committed on 19/04/2022 at 13:32.
Pushed by sitter into branch 'master'.

replace previous summary with tidy overview widget

it occurred to us that the old disk view was fishy on a number of levels

- it had a non exhaustive filter list of bad mounts
- this then raised the question why the mounts are missing (when e.g.
the user expected them to be there)
- the free space on a partition is not reflective of the space filelight
will be able to determine the use of (e.g. when +x is missing on a dir
that dir will be missing from the fileview)
- when talking about bind mounts (such as inside a sandbox) the two
sizes will almost never add up
- when inside a sandbox potentially only one valid path is available
($home) so having the previous view was slightly weird

the grand new overview widget simply displays three buttons to get right
into scanning root, home, or a custom path. root is hidden inside a
sandbox.

this preserves most of the spirit of what the previous view wanted to do
while scaling better and doing away with judgment calls on the edge
cases such as bind mounts
Related: bug 440152, bug 440151, bug 426594

M  +1    -0    CMakeLists.txt
M  +2    -2    src/CMakeLists.txt
M  +24   -28   src/mainWindow.cpp
M  +4    -4    src/mainWindow.h
A  +71   -0    src/overviewWidget.cpp     [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A  +23   -0    src/overviewWidget.h     [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
M  +0    -2    src/radialMap/labels.cpp
M  +1    -28   src/radialMap/map.cpp
M  +1    -2    src/radialMap/map.h
M  +2    -3    src/radialMap/widget.cpp
M  +1    -6    src/radialMap/widget.h
M  +22   -43   src/radialMap/widgetEvents.cpp
D  +0    -183  src/summaryWidget.cpp
D  +0    -40   src/summaryWidget.h

https://invent.kde.org/utilities/filelight/commit/38a71d1cbd46964f47eac1377788ebaabc5956d8