On Wed, February 16, 2011 11:57 am, John Layt wrote: > 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. > > 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. > > Anyway, I've started a page to document such things at > http://community.kde.org/KDE_Core/QtMerge , feel free to add stuff there. > David Jarvie, could you add something to the KDateTime entry?
Done. I hope it contains enough explanation - if you think it needs more, please say so. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm