KIO::convertSize(.,.) vs. KFormat::formatByteSize(...)

[Friedrich W. H. Kossebau]

Hi,

I see a few overlappings between methods in KFormat (KCoreAddons) and KIO 
(KIOCore), mainly this pair:

namespace KIO
{
typedef qulonglong filesize_t;
KIOCORE_EXPORT QString convertSize(KIO::filesize_t size);
}

[[Takes the binary unit dialect to use from a config file given by 
QStandardPaths::GenericDataLocation, QLatin1String("locale/") + 
QString::fromLatin1("l10n/%1/entry.desktop").arg(countryString), from the 
group "KCM Locale". Returns a number with the biggest unit where the exponent 
is not 0.]]


and

class KCOREADDONS_EXPORT KFormat Q_DECL_FINAL
{
    QString formatByteSize(double size,
                           int precision = 1,
                           KFormat::BinaryUnitDialect dialect =
                               KFormat::DefaultBinaryDialect,
                           KFormat::BinarySizeUnits units =
                               KFormat::DefaultBinaryUnits) const;
};


Questions:

Q1) What config files can be expected from KF5 modules?
So can KIO::convertSize(...) (which is already KDE4 code) expect such config 
files to exist? Only in a Plasma workspace platform, or? How is platform 
integration done in the KDE frameworks? E.g. in Unity, GNOME Shell, Win, etc. 
I would expect that any matching config data is picked, if there is, otherwise 
a hardcoded default. http://community.kde.org/Frameworks/Policies does not 
mention that yet, but I guess that has been discussed before?


Q2) Should KIO::convertSize(...) not use KFormat::formatByteSize(...) behind 
the scenes? (At least if it is turned into a deprecated method in the future?)
KIOCore currently already depends on KCoreAddons (due to KJob). Would be 
strange if programs built on KF5 display file sizes differently, due to 
different respected settings in the both methods.


Q3) Is double as type of parameter size for KFormat::formatByteSize(...) 
really a good choice?
I would expect the type to be rather qulonglong, like it is with 
KIO::convertSize(...). I have looked at many files with Okteta, but so for not 
seen a file with a fraction byte ;)


There are a few more toString-formatting methods next to 
KIO::convertSize(...), somehow I think those might be rather part of KFormat 
API as well. But first I would like to see those 3 questions resolved.

Cheers
Friedrich