John Layt wrote:
On Monday 14 February 2011 22:35:13 Stephen Kelly wrote:
You might think in terms of how much a typical KDE application ends up
using, but I'm thinking in terms of how much a typical Qt application
ends up using. Gregory is not going to end up using KLocale KConfig
KDateTime etc just because he wants to use kimap. I'm thinking in terms
of the Qt community and broader appeal - the people I interact with on
qt-interest, not the KDE community.
The thing is, most of what is in kdecore date classes really does belong
in the Qt classes, these are standard things on all platforms that Qt just
hasn't
implemented. QLocale is bizarrely incomplete in places. Why wouldn't Qt
want
to handle timezones correctly in this global internet age? Why wouldn't
they
want to format dates correctly? Why wouldn't Qt want to support what the
system localisation settings actually are? Some of this can actually be
fixed in Qt 4.x, we just need to convince Qt to accept the patches.
sebsauer has pointed out to me several times that QtMobility has a lot of
useful stuff in it, including handling mimetypes (possible replacement of
the kmimetype stuff?). I also note that the Qt time zone stuff is getting
moved along because of the needs of Qt mobility. I conclude that stuff which
QtMobility needs in Qt get added to Qt, and those things allow QtMobilty to
implement a platform. KDE does not hold that sway. Perhaps it's time to
'align the goals and requirements of QtMobility with those of KDE'.
KLocale is something that we need to take a step back from and ask why we
have
it and if there isn't a better more standard way to achieve those things.
We have it so our users can customise their locale settings, to add some
non- standard settings, and so apps can change the settings temporarily to
do
clever things. I've some ideas on how we can do those better.
Remove KLocale and the date classes from the core (non-ui) stack and a lot
of problems disappear, including their dependency on KConfig.
KConfig is going to be the big problem, fortunately not one I deal with
:-) Perhaps a KConfig backend to read/write from QSettings files would
remove most
Qt-only objections to using it in things like kimap? I'd hate to see us
have to ifdef support for two config systems in such libraries.
I agree that ifdefs shouldn't be used/needed. In extreme cases we can define
an interface to KThing and QThing and have the KThing implementation up on
the platform level. Proof of this concept here:
http://gitorious.org/grantlee/grantlee/blobs/master/templates/lib/abstractlocalizer.h
http://gitorious.org/grantlee/grantlee/blobs/master/templates/lib/qtlocalizer.h
http://websvn.kde.org/trunk/playground/pim/contacts/kdelocalizer.h?view=markup
Although for a config system, I don't think a solution like that would work
in the same way.
I think the real problem is mixed responsibilities of classes and libraries
in kde{,pim}libs. kconfig is respsonible for the file format as well as
de/serializing the data into strings/numbers/bools/dates/whatever. That's an
obvious responsibility of a config system, and it doesn't sound platformy.
However, kconfig is also responsible for knowing where the actual data files
should be, so it depends on KStandardDirs (platformy no doubt). That,
through other interdependencies means that it has the runtime dependencies
on daemons like ktimezoned etc. It doesn't have to be like that.
Could the way to find where the actual files are could be a QStringList,
which is then supplied through the Hollywood principle (don't call us, we'll
call you):
instead of (pseudocode)
(somewhere in kconfig)
KStandardDirs::getConfigFile();
have something like:
someKConfigInstance.setFilePaths(KStandardDirs::getConfigPaths());
The KConfig returned by KGlobal (which would also be in the platformy tier)
would be pre-setup with this.
Or a bit of a virtual interface could be used instead of Hollywood.
The point is that there are many ways of separating functionality from
platform, and it all comes down to what you've heard to be a good idea a
million times: separating responsiblities.
Cheers,
Steve.
