Disk usage does not add up in disk space widget

[marmarek]

Qubes OS version:

R4.0

Affected component(s):

qui-disk-space

---

Steps to reproduce the behavior:

Open disk space widget.

Expected behavior:

Total disk usage represent what is really available.

Actual behavior:

Total disk usage shows half of actual usage, listed below.

According to sudo lvs qubes_dom0/pool00, 60% is the right number.

---

Related issues:

#3241

[tasket]

Just thought I'd mention there is also a related labeling problem: "Disk usage" is shown but the percentage bar appears to show the un-used portion.

I think inverting the percentage in the bar and showing the amount Free/un-used GiB in text form would offer the most clarity (its easier for users to make decisions about the about of free space they have left to work with).

[tasket]

Just thought I'd mention there is also a related labeling problem: "Disk usage" is shown but the percentage bar appears to show the un-used portion.

I think inverting the percentage in the bar and showing the amount Free/un-used GiB in text form would offer the most clarity (its easier for users to make decisions about the about of free space they have left to work with).

[andrewdavidwong]

Wondering if this warrants a new issue or not, but I'll include a brief mention here for now.
In addition to the disk-space-widget bug(s), this is a suggestion for better overview accuracy from a human UX perspective. Consider the question whether adding a sub-menu in the disk-space-widget, on which for example hovering mouse-over expands a side-menu that shows how various of AppVM's and Templates uses system disk-space, would be desirable or not. (i.e. starting from the biggest disk-use from top to lowest values value at bottom, maybe also separating AppVM's and Templates, i.e. AppVM's first before Templates. Also maybe like disk-space-numbers + %-based-bar-graph). Or maybe other different solutions like it. Maybe old code from the old Qube Manager could be borrowed here to expand such a disk-space-widget sub-menu?

Essentially giving the user an idea where disk-space is used. For example I noticed some people have a hard time to read the number prints from qvm-ls --disk, while other people have no issues reading the semi-raw terminal out-put. But even if good at reading the qvm-ls --disk output, it would still be easier and quicker to have the widget include such information.

If system resources for calculation sub-disk usage is an issue, maybe it can be only triggered when hovering over the sub-menu (similar to how qvm-ls --disk takes a second in dom0 terminal)?

@Aekez, please file a separate issue for this.

[andrewdavidwong]

Wondering if this warrants a new issue or not, but I'll include a brief mention here for now.
In addition to the disk-space-widget bug(s), this is a suggestion for better overview accuracy from a human UX perspective. Consider the question whether adding a sub-menu in the disk-space-widget, on which for example hovering mouse-over expands a side-menu that shows how various of AppVM's and Templates uses system disk-space, would be desirable or not. (i.e. starting from the biggest disk-use from top to lowest values value at bottom, maybe also separating AppVM's and Templates, i.e. AppVM's first before Templates. Also maybe like disk-space-numbers + %-based-bar-graph). Or maybe other different solutions like it. Maybe old code from the old Qube Manager could be borrowed here to expand such a disk-space-widget sub-menu?

Essentially giving the user an idea where disk-space is used. For example I noticed some people have a hard time to read the number prints from qvm-ls --disk, while other people have no issues reading the semi-raw terminal out-put. But even if good at reading the qvm-ls --disk output, it would still be easier and quicker to have the widget include such information.

If system resources for calculation sub-disk usage is an issue, maybe it can be only triggered when hovering over the sub-menu (similar to how qvm-ls --disk takes a second in dom0 terminal)?

@Aekez, please file a separate issue for this.