[PATCH] Add support for JEDEC/metric standards to KLocale::formatByteSize

[Thiago Macieira]

Michael Pyne wrote:
>I've been disabused of some preconceived notions I had (for instance, I
> regret typing "NO ONE NEEDS DECIMAL UNITS" (in all caps no less)). 
> Hopefully I've made some of my technical points in the midst of it all.

I don't regret still having that opinion. Especially because we're not 
changing the world here by using metric units, but we'd be adding more 
confusion.

>* Networking has from what I can tell always used powers of 10 when
> referring to i.e. bandwidth and bitrate.

Not always. An E1 link is 2 Mbit/s. That is, 32 channels of 64000 bits per 
second, or 2048000 bits per second. So it's the same problem as the floppy 
disks.

But that's the only case I can think of. So you could file it away as "5% 
rounding down", especially since the higher-level links (E2, E3, STM-1, 
etc.) are clearly rounding down.

>* Floppy disks are just stupid because their "1.44 MB" is really 1024 *
> 1440 or something like that (i.e. mixing base-2 and base-10).
>* Beyond that, KB have traditionally been powers-of-2, as confusing as
> that is to new computer users.
>
>In order to erase some of the confusion, an IEC standard (addendum to
> IEC 60027-2) was developed in 1999 to add new units which were
> specifically reserved for base-2 binary units (and is what we see now
> in KDE 4.  Bug 57240 pertains).  This is where KiB, MiB, etc. come
> from.
>
>Metric units have been standardized, with very minor revisions, for
> centuries now, and therefore most of the world tends to get computer
> units confused upon introduction to "kilobytes", "megabytes", etc.

The prefixes apply for metric units. Byte is not a metric unit. Therefore, 
the prefixes don't apply. For what it's worth, people don't even agree on 
what a byte is.

>The point to all this is that I think now that it would make sense to
> have support for the 3 different standards in kdelibs.  Many people do
> prefer the traditional/JEDEC-style units, and even without that (and,
> for that matter, with that), there are areas where metric decimal units
> are needed (networking, hard disk sizes).

Well, I disagree. My argument is that it adds more confusion, since other 
applications and operating systems will not follow the KDE settings. The 
worst case scenario here is that two different applications show, side-by-
side, two different values with the very same units (MB for example) for 
the same object.

I don't want bug reports about "KDE detecting the size of my disk wrong", 
even if the only case we'd get it "wrong" would be if we got it larger.

For 25 years, UIs have used binary units. Every single computer-expert-
wannabee knows that.

With that in mind, I oppose the patch.

However, given the flamewar, I may be a won-out vote and I'll accept that. 
I'll accept because the only case where we'd be showing the "wrong" values 
("wrong" defined as "different from all other systems and UIs, including KDE 
4.3 and earlier") if and only if the user explicitly made that choice.

>1) Add a GUI to localization settings KCM to allow the user to select
> their preferred unit style.  Over the past week I've heard input from
> numerous users who all want one of the three ways (including
> metric/decimal units), so I think it would make sense to be in the GUI
> as it's (apparently :) a very sensitive issue for many.  I will work on
> this.

I oppose this even more.

>2) Go through the KDE applications we maintain and use formatByteSize
> where appropriate.  What I mean by that is that whenever possible we
> should respect the user's units.  However, when we report download
> speed, that should be in decimal given existing practice, even for
> users with JEDEC.  When reporting hard disk capacity (i.e. in
> KDiskFree) we should use (or at least show) decimal units even for IEC
> or JEDEC.  Likewise, when a flash drive is inserted it probably makes
> the most sense to use IEC unless the user has already selected JEDEC
> when displaying the total size (individual file sizes would still be
> displayed per user's settings).

Sorry, that makes no sense.

We should fix all applications to use formatByteSize. Once done, we stop. 
See next point.

We shouldn't use different standards for different things. That would lead 
to confusion why some files of the right size don't fit, where in other 
circumstances they do and there's left-over space.

For example, detecting a DVD device as 4.7 GB and then trying to store a 
4.5 GB file in it, and failing because the first GB was decimal and the 
second was binary.

The fact that the industry can't agree on what they use as units should 
not be reflected in the UI, by bringing the disagreement into it.

>3) I can't find the email right now but I do remember reading an email
> from someone on our i18n teams who was having trouble with the various
> applications using their own units (sometimes they meant decimal,
> sometimes binary, etc.) so the /other/ thing I'd like is to go through
> and correct applications to use formatByteSize where appropriate.  I
> can run grep as well as anyone else so I suppose I can work on this.

This is the first part of your point #2 above, which is the only part I 
agree with.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090712/b873a170/attachment.sig>