[REMINDER] Upcoming KDE 4.0 Milestones

[David Faure]

On Thursday 26 April 2007, Allen Winter wrote:
> 30 April: Last chance for big changes to kdelibs
> 1 May: kdelibs Soft API Freeze

I suggest that kdelibs/kutils is exempted from this freeze. It's still a random collection of things,
which need to be sorted out.
Most of it is about settings stuff (I can take care of the rest today), but kcontrol hasn't even 
been looked at yet...

ksettings/componentsdialog.h  ksettings/pluginpage.h
ksettings/dialog.h            ksettingswidgetadaptor.h
ksettings/dispatcher.h
kcmodulecontainer.h  kcmoduleproxy.h
kcmoduleinfo.h       kcmultidialog.h  kpluginselector.h
kcmoduleloader.h

and kmultitabbar.h, which I'll move to kdeui.

Since all of this seems related to settings: if we don't want to pollute kdeui with so
many classes related to settings (do we need them all?),
then maybe libkutils could stay and be renamed to libksettings?

I asked Matthias Kretz about this some time ago and he said:
> I was thinking about that yesterday, too. And was even thinking a bit
> further - whether ksettings should really stay in kdelibs. For one, in 3.x
> times, kontact (the main user of the classes) could not make use of any
> changes in KSettings because it stayed compatible to older kdelibs
> versions. Also I'm not happy with the classes now that I see better
> possibilities to solve the problem. (What I mean is not the idea of
> KSettings, but the implementation.)
>
> Perhaps the KCM stuff should move to kdeui, and probably the
> kpluginselector too - though there's also been discussion that it's not
> what applications want to use. Then all that's left is the KSettings
> classes which could either be moved into projects that use them or kept as
> a libksettings. But I believe KSettings is not ready for 4.0 yet.
... which is my point too :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).