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

[Friedrich W. H. Kossebau]

Hi David, Michael, everyone,

Am Freitag, 24. Januar 2014, 09:40:00 schrieb 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 :)

Now, KFormat::formatByteSize(...) takes as default values 
KFormat::DefaultBinaryDialect and KFormat::DefaultBinaryUnits. Both settings 
mean that something should be chosen that is default. So from an API point of 
view
	KFormat::formatByteSize( byteSize )
and 
	KIO::convertSize( byteSize )
should behave and look the same, right? :)
(Currently just the used defaults are/can be different)

You say "consistency across all KDE applications":
As a user I would like consistency across all my apps :) I do not (want to) 
care what programming language and toolkit the developers preferred to know 
what to expect in the UI. Programs should simply adapt to the system settings.
And the system is: the environment the program is running in, either something 
fixed when creating the binary/package (Android, Sailfish, BB, Windows, OSX) 
or something less fixed (Plasma Workspace, LXDE/Razor, GNOME Shell, Unity, 
Enlightenment, XFCE).

So for systems where the default of a certain parameter is an option, I expect 
the code to read that option in, and where it is not, I expect it to be 
hardcoded to what makes sense on the system. For fixed systems that could be 
compiled in hard, for less fixed this needs some runtime switching, either by 
plugin or if-else code.

In a Plasma Workspace I expect the bytesize parameter defaults to be 
configurable, like it used to be. And any program which wants to properly 
integrate into that environment should pick these defaults up. Like I expect 
the position of the Cancel/Ok buttons to be picked up :)
Possibly Plasma Workspace might be the only one where it is configurable, but 
fine. That is one of the added-value of it :) (LXDE/Razor might be interested 
to have it as well)

Or what is the direction? Maybe I misunderstood the intention of KF5, but I 
thought it should be more nice Qt5 extension and not depend on lots of the 
typical KDE runtime, unless useful for integration in a Plasma workspace (or 
any other environment from KDE).

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

"... for which we have...": well, we have it in Plasma Workspace. There we 
should use it, sure.
But we have not in Sailfish or on Android (or would you think it makes sense 
to have a tuning app for all programs which use KF5? I do not.). And I doubt 
people interested in KF5 would like their code to still reach out for all 
those config files on those platforms as well. Especially as their apps are 
additional apps, that IMHO should integrate smoothly with what is already 
there and not suddenly start to show different formattings for file sizes, 
dates etc. Or?

Now, KCoreAddons is a "Functional Qt Addon" in tier 1, KIO is a "Solution" in 
tier 3. Hm. I wonder if that means anything for platform/system integration. 
For comparison, QtCore is expected to integrate with the platform/system.

The current KF5 policies seem to not yet mention the issue of platform/system 
integration. Has there been some discussion on this before already?

Cheers
Friedrich