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.