[PATCH] Add support for JEDEC/metric standards to KLocale::formatByteSize
mpyne at kde.org
Tue Jul 21 00:58:19 BST 2009
On Friday 17 July 2009 17:04:13 Chusslove Illich wrote:
> > [: Michael Pyne :]
> > I appreciate the feedback provided. My patch is committed more or less
> > unchanged (I had to correct some API documentation minor flaws). [...]
> Sorry, only now I got to pay attention to the order of arguments to new
> QString formatByteSize(
> double size,
> int precision,
> BinaryUnitDialect dialect = KLocale::DefaultBinaryDialect,
> BinarySizeUnits specificUnit = KLocale::DefaultBinaryUnits
> ) const;
> Wouldn't it be more convenient to have the specific unit as third argument?
> Because it seems to me that the need to select that one should be much more
> frequent than to select the binary dialect.
Honestly I could see only a few reasons to ever not use auto (but then I
either didn't get to read all of Marcel's reasoning about it before he
submitted his patch a few months ago or didn't recall it).
For more honesty I'm not even the best one to be touching this at all, I just
happen to be the one who got fed up enough about people arguing over it to do
something about it. ;)
Whichever is the best method is what I want, so if no one has a reason to
maintain the current order I'm fine with switching the parameter order.
A couple of non-related things to mention is that I didn't see a ton of KDE
code that wasn't using formatByteSize (although my search was basically only
for KB, case-insensitive). Two exceptions were KPilot which seems to use kB
as 1024 without localization anyways, and KSysGuard in some sensor-auto-
leveling code. I didn't really want to touch either.
Also I had wanted to make the precision parameter default to 1 but that
interferes with the existing formatByteSize() function, and I couldn't see a
good reason to change the name (formatByteSizeSpecifically? ;) but that's
another area where we may want to think -- do we want the same name or a
different one for this method?
- Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel