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

[Michael Pyne]

On Sunday 12 July 2009 05:40:57 Thiago Macieira wrote:
> 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.

Well for this much I agree that we'll never been able to make JEDEC units 
magically turn into metric ones in the computing industry just by flipping a 
switch.

At the same time though I don't like people telling me what units I am and am 
not allowed to use on my own computer so I don't think I can in fairness say 
the same thing back.  And so that's what I mean when I say I regretted my 
comment.

> >* 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.

Well no matter what we do I wonder what people who are /really/ concerned 
about units will do with these cases.  If using JEDEC units is too confusing 
for people with the 7% error then I'm not sure how 5% error is magically OK.  
But at the same time though I think it's something that won't come up in 
practice (how close does the bitrate on E1 links come in practice to their 
rated capacity?)

> 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.

And what JEDEC does is they refer to the units strictly as "KB", "MB", "GB" so 
in that regard they're not even trying to claim adoption of the metric units 
(which means that if we do add "long form" translations the KB would still be 
KB instead of kilobyte for JEDEC).

> >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.

Well I think for such things as memory sizing in KInfoCenter and showing 
magnetic media capacity in KDiskFree it would be useful to select specific 
units (which is what this patch is for) but if we never add a GUI option to 
expose the hidden default binary locale option that's fine too, if we're 
worried about confusing users on units.

> 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.

Well for some reason a sizable portion know it but don't care.  FWIW

> 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.

I assume you're referring to using kB/MB/GB as metric?  I agree we'll be 
different from essentially everything else out there in that regard, but the 
only reason I'd made it possible to be set as default is just because there is 
apparently user demand.

> >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.

Works for me, it gives me more time to get kdesvn-build git support improved. 
;)

> >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.

Well my reasoning is essentially that we want to show what the "rated 
capacity" is (in the manufacturer's terms i.e. metric) and then when the 
"actual capacity" is (in the standard UI units).  i.e. something like making 
the DVD icon label "Empty 4.7 GB DVD (holds 4.37 GB [or GiB])".  Of course we 
can just call it a "single layer DVD" or such but we still get the issue where 
the user wonders where the other 7% went.

> >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.

:)

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090712/8a91802b/attachment.sig>