Bug 219932 - Difficult to distinguish between bytes, KiB, MiB
Summary: Difficult to distinguish between bytes, KiB, MiB
Status: RESOLVED INTENTIONAL
Alias: None
Product: dolphin
Classification: Applications
Component: view-engine: details mode (show other bugs)
Version: 16.12.2
Platform: Ubuntu Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
: 227747 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-12-24 11:21 UTC by Dotan Cohen
Modified: 2017-09-03 14:24 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.0


Attachments
screen mockup of size-unit font scaling (50.34 KB, image/png)
2011-10-18 02:12 UTC, Felix
Details
konqueror 3, for comparison (57.60 KB, image/png)
2011-11-03 20:28 UTC, Felix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dotan Cohen 2009-12-24 11:21:38 UTC
Version:            (using KDE 4.3.4)
Installed from:    Ubuntu Packages

Please add an option to change the way Dolphin distinguishes between bytes, KiB, MiB in filesize listings to something more visible. Currently, Dolphin simply lists the units after the value. However, this is often hard to distinguish. Adding an option to show the different orders of magnitude in different fonts, sizes, or colours would be very helpful.

Of course, I only mean to suggest that the display of the Size column should be affected. The remaining columns should appear just as they are.

Thanks.
Comment 1 Felix 2011-10-17 17:02:00 UTC
I agree with this -- I would say the easiest way to handle it is actually to bring back the "show file sizes in bytes" option from Konqueror 3. Showing all sizes in the same unit is by far the easiest and quickest way to see what's bigger and what's smaller -- the bigger numbers are visually bigger!

e.g.

4.1 MiB
849.1 KiB

versus:

4322347 bytes
869459 bytes

In bytes, it's immediately obvious that the first file is bigger, without even having to read the numbers. Currently, I'm always misreading the sizes when I've got some files that have more significant figures in a KiB size than a nearby MiB size.

Another alternative is to simply display everything with a fixed number of figures, aligned at the decimal point:

004.122 MiB
849.081 KiB

Then the eye won't be drawn to the visually different-size numbers, and one can just scan down the units column and look for MiB, KiB, B... but I argue that displaying in bytes is better, because reading any "units" format still requires two steps -- mentally register what units you've got, then glance left for the number. That first step already requires spinning up the language centres of the brain (slow), whereas comparing two sizes in bytes can be done with the much more primitive reptilian "that one's bigger; I'd rather eat the bigger one!" impulse (fast) ;)

~Felix.
Comment 2 Dotan Cohen 2011-10-17 17:47:00 UTC
How about showing bytes in a slightly smaller (-2px) font, KiB in the regular font, MiB in a bold font, and GiB in a bold+italic font? I know that sounds convoluted but from a users point of view it would make the comparison much easier (as Felix mentioned, it works on much lower-level brain functioning).
Comment 3 Felix 2011-10-18 02:12:57 UTC
Created attachment 64657 [details]
screen mockup of size-unit font scaling

Here's what Dotan's suggestion of scaling MiB +2px and B -2px would look like -- interesting, and I think it could work, but I still favour the option to display sizes in bytes (with a thousand-separator).
Comment 4 Felix 2011-10-18 02:31:05 UTC
Oh, and I wanted to add -- one thing that still bothers me is the different numbers of significant figures for file sizes. i.e. right now, if something is a single-digit number of GiB, MiB, or KiB, its size is displayed to less precision than if it's a 3-digit size in that unit, e.g.:

4322347 bytes is displayed as "4.1 MiB"
but
869459 bytes is displayed as "849.1 KiB"

This means the display gives twice as much information (precision) about the size of the file in the latter case. I find this both visually and mentally jarring. I don't think displaying extra decimal places for the smaller numbers would help, either, because this introduces two problems:

1) one has to go hunting for the decimal point (extra mental time to figure out how big something is)
and
2) now the precision problem is reversed from a relative one (significant figures) to an absolute one (measurement resolution) -- sizes of small numbers of KiB, MiB, and GiB are more precise than larger ones, e.g. 4.123 MiB is effectively to the nearest KiB, whereas 123.4 MiB is only to the nearest 100 KiB.

Overall, I still think that simply displaying sizes in bytes is the simplest solution, as it's always perfectly precise, and actually requires less programming to implement than the existing display logic :)

~Felix.

PS: I originally landed here because I wanted to make this feature request for Konqueror; I'm hoping that any implementation in Dolphin would be available in both.
Comment 5 Felix 2011-11-03 20:28:26 UTC
Created attachment 65208 [details]
konqueror 3, for comparison

The latest release from the Trinity KDE3 fork actually works decently in my distro, so I installed it. Here's a screen shot of the same batch of files I used in my mockup, for comparison.

(I think I'll actually uninstall KDE4 and use Trinity now; it's a lot more responsive. I'd forgotten what it was like to have Konqueror respond instantly to clicks (this on my underclocked netbook, even) :) )
Comment 6 Peter Penz 2011-11-04 06:32:18 UTC
I currently don't have time to add an option for this for the next release because of some more severe issues that need to be solved, but I agree that the mixed units are not useful. The Windows Explorer and Apple's Finder us always KB as unit and it would be only a minor patch to change Dolphin to this (-> could be done for 4.8 already).

My proposal would be that for small KB sizes (e.g. < 10 KB?) a decimal is shown e.g.:
5.2 KB
3.1 KB
7.8 KB
and for sizes above only non-decimal values are shown:
       23 KB
      512 KB
   10,234 KB
5,644.343 KB

Would this be sufficient or do you want to have an option to switch between Bytes, KBytes and the current behavior? If an option is wanted this most probably must wait until 4.9...
Comment 7 Peter Penz 2011-11-04 06:34:22 UTC
... oh and I think it might be a good idea to skip the "KB" postfix in each cell and just change the header to "Size (KB)" (?)
Comment 8 Felix 2011-11-04 07:26:51 UTC
I could probably live with everything being in KB, but I really would prefer the old 'bytes' feature back -- it's one of those things about KDE4 that made me think, "we had it and it worked; why'd they break it?"

It also has the side effect of being a quick way to see if two files might be identical. (By no means a rigorous test of course, but for file formats that change size every time you save them [e.g. documents & text files] it's useful.)

On making the KB option omit the units on displayed values: I think that's not a good idea, since the convention is that a unitless number filesize is in bytes (e.g. ls, and the old bytes display from Konqueror 3 and numerous other file managers). As far as I know, even Apple has always kept the suffix "K" for file sizes -- imitating that and shortening KB to K would be fine (or perhaps "Ki" if you're feeling adventurous/pedantic :) ).

~Felix.
Comment 9 Dotan Cohen 2011-11-04 15:04:41 UTC
Hi Peter. I must counter that I would prefer _not_ to see everything in bytes. Please make this optional. Additionally, in my opinion the units _should_ be next to the size, not at the top in the column title. How far do we want the user's eye to travel? And you certainly don't want to add a vertical component to that travel! (human eyes scan left-right just fine, but vertical scanning is extremely tiring)
Comment 10 Dotan Cohen 2011-11-04 15:06:53 UTC
Regarding the KB vs. KiB issue, please do keep it at it's current KiB units! This is one of the really nice subtleties of KDE.
Comment 11 Peter Penz 2011-11-04 21:08:41 UTC
It seems I cannot make all of you happy to 100 % ;-) However I've to decide for one direction as at least for 4.8 making this configurable is no option and now have pushed the following fix:

- The size-column shows everything in KiB (or in KB dependent on your global setting in system-settings -> Locale -> Country/Region & Language -> Other -> Byte size units). I've decided against using Bytes as unit because the numbers get very large for common files like e.g. a JPEG with 2,345,234 Bytes and I need to focus for the main target group of Dolphin (see http://dolphin.kde.org/philosophy.html).

- The unit stays next to the size as Dotan suggests in comment 9

If there is still a demand for having Bytes I'd kindly ask to open a new wish for this (I'm open to make this configurable if I've the impression that there is a demand for a user group > 0.1 % ;-)) Thanks.
Comment 12 Peter Penz 2011-11-04 21:09:10 UTC
Git commit 39992aad7096d5caa6b9b6cb1e28f6ea2ef234ca by Peter Penz.
Committed on 04/11/2011 at 21:54.
Pushed by ppenz into branch 'master'.

Don't use mixed units in size-column of details-view

This makes it tricky to compare the filesizes without adjusting
the sort-order, so now all sizes in the size-column are shown
in KiB or KB (dependent on the KLocale setting).

BUG: 219932
FIXED-IN: 4.8.0

Related fixes:
- Stay consistent with the rounding when using the KiB/KB unit
  in the statusbar.
- Fix sorting-by-size issue for folders
- Show "Unknown" in the size-column when the number of items
  cannot be determined.

M  +7    -1    dolphin/src/dolphinviewcontainer.cpp
M  +8    -3    dolphin/src/kitemviews/kfileitemlistwidget.cpp
M  +16   -6    dolphin/src/kitemviews/kfileitemmodel.cpp
M  +48   -36   dolphin/src/views/dolphinview.cpp
M  +6    -0    dolphin/src/views/dolphinview.h

http://commits.kde.org/kde-baseapps/39992aad7096d5caa6b9b6cb1e28f6ea2ef234ca
Comment 13 Peter Penz 2011-11-04 21:12:28 UTC
(In reply to comment #11)
> - The unit stays next to the size as Dotan suggests in comment 9
... and as Felix suggested too in comment 8
Comment 14 Peter Penz 2012-04-09 07:56:33 UTC
I'm sorry but I need to reopen this bug again because of the following commit that I've done for bug 289850:

   "Revert the 2.0 decision to always use KB for file-sizes
    
    The feedback on bugs.kde.org has shown that the previous behavior
    (= show size with best-matching unit) is preferred by most users.
    I initially wanted to make this configurable, but for implementing
    it in a non-hacky way extending KLocale from kdelibs would have
    been required. I'm not sure whether the usecase in Dolphin justifies
    having such a configuration in KLocale - however as kdelibs is frozen
    at the moment this is no option and the old behavior has been
    restored.
    
    BUG: 289850
    FIXED-IN: 4.9.0"
Comment 15 Peter Penz 2012-05-01 20:03:05 UTC
*** Bug 227747 has been marked as a duplicate of this bug. ***
Comment 16 Frank Steinmetzger 2012-05-03 19:46:22 UTC
I don't quite understand how it is hacky (but then of course, I don't know the internals). We've had the automatic mode earlier (and will have again apparently), and the kiB-only in 4.8.
So both seem to work. Someone said that if there was an option for this, it should be more of a KDE-global setting. Well, since the Dolhpin part is used in a number of areas of KDE, it is already semi-global. So I'd still welcome an option.

As a sidenote:
For me, the mixed mode became even more difficult to read ever since the writing in all the columns became non-black---for whatever reason (what percentile of the userbase doesn't have the filename in the far left column?). The reduced contrast makes it quite harder to read.
Comment 17 Jeroen van Meeuwen (Kolab Systems) 2012-08-24 16:19:54 UTC
Resetting assignee to default as per bug #305719
Comment 18 Nate Graham 2017-09-03 14:24:26 UTC
I'm afraid it seems there's no way to make everyone happy here. But the vast majority of people prefer mixed units, and this is the way pretty much all other file managers have things, so it's not some kind of Beastly Abberation Against Man.