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

[David Faure]

On Thursday 23 January 2014 23:43:36 Friedrich W. H. Kossebau wrote:
> 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);
> }
> 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;
> };

I think it makes sense to have two methods, at two different layers.
The KFormat one is like Qt: the caller of the method decides what they want.
The KIO one is as we like things in KDE, very often: it takes into account the 
user's preference, for consistency across all KDE applications.

The KF5/Qt5 trend is to make that happen automatically behind the scenes of 
the "lowlevel" (e.g. Qt) API, but that doesn't work for a method that is so 
low-level that it actually takes the settings as parameters :)

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

Well, does a setting exist for "how to format byte sizes" (including the 
choice between GB and GiB) in all these frameworks? I seriously doubt that....
So it seems to me that picking this from a KConfig file for which we have a 
KCM is the only solution?

> Q2) Should KIO::convertSize(...) not use KFormat::formatByteSize(...) behind
> the scenes?

Yes, quite probably, unless we're missing something about the details of what 
it needs. Feel free to dig into that :)

> 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 ;)

Indeed. I wonder if this is historical from before qulonglong existed (you 
know, a few minutes after the Big Bang, or 2001, in other words).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5