On Sunday 26 January 2014 00:20:02 Friedrich W. H. Kossebau wrote:
> > > };
> >
> > 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? :)
No, not necessarily. Not with the rationale I wrote above.
If the two methods behaved the same we wouldn't need two.
> 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.
Well we can't do much about GTK or Java apps :)
But yes, by KDE apps I meant more precisely "apps using KIO".
> 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).
If you know how to get the "do you want GB or GiB" setting in all these
environments, I'm very interested to hear that :-)
This is my issue with all this: AFAIK nobody else cares about this setting.
> 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.
That's the idea of the high-level API (KIO).
There's also the use case of an app that wants an exact setting.
It's like the difference between "give me the background color from the
palette" (high level) and "give me gray" (low level) - Qt supports both.
> 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 :)
Yep, works with that one too: if you want environment-dependent button order
you use QDialogButtonBox ("high level"), if you want app-specific button order
you use QHBoxLayout ("low level").
> 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)
Yep.
> 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?
OK. But I'm not sure what that means in practice. Checking KConfig only in a
Plasma/Razor workspace, and hardcoding the setting in other workspaces since
we are not aware of them having this setting?
If I understand correctly, you would want
if (in kde workspace)
readKConfig
else
use defaults
I just can't see how this is better than
readKConfig
given that if you're not in a kde workspace, you can't change the settings
anyway :)
Of course it opens to better integration with other environments later on,
which I'm completely in favour of.
The if() ugliness can also be turned into a plugin based solution like we did
in KMessageBox for dependency inversion reasons:
kwidgetsaddons/src/kmessageboxdontaskagaininterface.h
is implemented by
frameworkintegration/src/integrationplugin/frameworkintegrationplugin.cpp
(that plugin is only loaded in a KDE workspace)
You can add a similar interface in KIO and implement it there too, I have no
objections to that.
> 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.
Yes, but not all of QtCore. See the above discussion on low-level vs high-
level.
I don't mind if the high-level method moves down to KCoreAddons BTW. I just
think both are needed.
> The current KF5 policies seem to not yet mention the issue of
> platform/system integration. Has there been some discussion on this before
> already?
Well, for things coming from Qt we have KStyle and the QPA theme plugin, and
for things coming from KF5 that we don't feel belong in Qt we have interfaces
implemented by frameworkintegrationplugin.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
