why kdelibs?

[Diederik van der Boor]

Op zaterdag 30 oktober 2010 22:43:50 schreef Stephen Kelly:
> Alexander Neundorf wrote:
> > I think BC is less important that SC.
> > If a KDE5 would just require a recompile, and maybe some changes in the
> > cmake scripts (like additional find_package(SomeKLibrary)), this
> > shouldn't be a too big problem for KDE.
> > If it would mean people have to rewrite their apps, as they just did for
> > KDE4, it might be deadly for KDE I'm afraid.
> 
> I think the big difference is that KDE4 introduced many new and different
> technologies that needed to be ported to (akonadi, plasma for example),

Let's not forget that Qt4 changed a lot of behaviour in classes.
This tore out the remaining solid foundation of apps.

> whereas reorganizing kdelibs involves shuffling things around and renaming
> libraries. So you'de use, for example, KPlatform::Locale instead of KLocale
> (which uses KConfig, KStandardDirs etc), whereas Gregory would use
> KLibs::Locale (which uses possibly self implemented or contributed
> interfaces which use QSettings, etc).

I think this is being taken a bit too light.
If things are just search/replace that's all fine, but moving stuff to Qt 
could mean behaviour changes unless some compatibility wrapper is set.

Some rough statistics on porting an app of 120 source files: (KMess)
From KDE 3 version to KDE 4 alpha we needed 654 commits, of which:
- 190 commits to get things to fully compile again
- 80 commits before basic chat worked again.
- 180 commits until the essentual porting was fully done
- 200 commits until an alpha could be released.

This is 120 source files and the only new thing it used was the QModel* stuff.
Eventually we voluntary improved a lot of other stuff, but the porting effort 
is not something to be repeated ;-)

I can't stress enough it needs a good plan to limit impact on apps.
Perhaps in the form of some compatibility layer, i.e let those kdelib classes 
become wrappers/adaptor classes for the stuff that's been moved to Qt.

> Until we try some things out we won't know what the impact on kde apps
> would be.

Making things concrete would certainly help :)

Diederik