GNOME Bugzilla – Bug 94691
Size column should always use the same unit
Last modified: 2021-06-18 15:54:33 UTC
Currently the size column uses different units depending on the size of the file. This makes the column hard to read/follow vertically, especially when scnanning the list for a particular value or trait. The unit used should always be the same (Kb would be a good choice). This is the behaviour of the Windows file manager, for example.
Created attachment 15929 [details] [review] adds new function to eel vfs extensions
So, I was trying to think of a way to fix this. The solution that I came up with was to add a new function to eel-vfs-extensions, that basically takes an extra variable, the format file size. I'm just a little unsure how to present this type of thing in the UI. Comments?
I just noticed a small problem: a file size of say 10 bytes will appear as 0.0 KB, giving the incorrect impression that the file is empty. Maybe the correct thing to do is to always round up, rather than to the nearest value. Another nit: it should be KB not K.
Glynn, could you update the patch to match the comment above? I think that makes more sense than showing files between 0 and 1000 bytes as 0.0 KB
It should actually be kB if division by 1000 is employed, and KiB if division by 1024 is employed.
The docs styleguide says to use "K" for 2^10 and "k" for 10^3, so "KB" should be what we use until we hear otherwise... cc'ing Pat just to make sure though :)
*** Bug 124731 has been marked as a duplicate of this bug. ***
I believe that this bug is a duplicate of 127175.
Alexander: this bug is about what units to use when displaying file sizes in list view, not about how to write the unit names. In fact I think bug 124731 is a duplicate of bug 127175 not this one.
This isn't really an enhancement, per se; note that the current behavior is 'hard to read', etc. Marking minor.
is that still an issue ? the size column seems to have the number of elements now.
Sebastien: I'm not sure what you mean by "number of elements". The behaviour I described in the bug summary has not changed (as of 2.8.2), so I'm reopening (and updating the version field)
right, I was looking on a directories list which display the number of elements on the directories instead of the size of the folder. Still here with 2.9.2
Still in 2.22, too. (Although incidentally, I noticed that OS X doesn't use the same unit for the whole column either-- it happily mixes KB, MB and GB....)
Same units as in, "we should always just use bytes in the column", same units as in "we should display the size of directories and not the number of items within it", or same units as in classification of units (as in g_format_size_for_display(), which is what the attached patch to this bug essentially is)? Can we be a bit less vague here?
Hi Walton, I think my original report was clear. If not, what was meant was "we should always just use bytes in the column" (althought the original suggestion was Kb not bytes).
That would be rather non-useful in my Podcasts folder, where most of the files are tens of megabytes. That could be worked around by making the choice of unit folder-specific (rather than the current file-specific). But that would mean dropping a small README file in the Podcasts folder would either change the units used to display the size of every other file in the folder, or show a size of "0 MB" for the README file.
*** Bug 618269 has been marked as a duplicate of this bug. ***
MPT, I like your idea of making the unit folder-specific (e. g. by generating on the fly). I think we should to employ (2?) decimal places. If there is the case of very small files in the folder, we can still say: < 0.01 MB. This would make clear that it is not zero (does it?) and still say something about the size. On the other hand, use of the greater or less than operator may be confusing to users. But is it more confusing than mixed units? I for one don’t think so.
*** Bug 627925 has been marked as a duplicate of this bug. ***
Still in 3.1.4.
Just as an example: For the ownCloud file manager, I used MB as standard unit. This (already old) screenshot shows it: https://joindiaspora.s3.amazonaws.com/uploads/images/644f3a4494ddb6d3b861.png Files above 1 GB are just displayed as > 1000 MB, files below 100 KB are just displayed as < .1 MB. In addition, the file size is represented by the text color. The detailed file size is available on hover.
*** Bug 740353 has been marked as a duplicate of this bug. ***
Just my 2cents. I, for one, would report it as a bug if my file browser always used kB even when MB is more appropriate for that file. Example: 147 536 kB This is noisy, too many digits. 147.5 MB Much nicer, shorter, easier to com 0.008 KB Again, too much noise. 8 bytes Much simpler. Using variable unit is not a problem when sorting by size, items are sorted correctly. Also, the precise size in bytes is always shown in the Properties dialog. However, if it's really important for some use cases to always use the same unit, maybe this is the case to introduce another column "Size in bytes" that the user enable? We have something similar for "Type" (which groups similar types) and "MIME Type".
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.