"Cornelius's grand plan" - Merging KDElibs into Qt

[Matthias Fuchs]

Am Sonntag 31 Oktober 2010, 13:45:48 schrieb Matt Williams:
> On 31 October 2010 12:37, Modestas Vainius <modestas at vainius.eu> wrote:
> > Hello,
> > 
> > On sekmadienis 31 Spalis 2010 14:04:28 Matt Williams wrote:
> >> On 31 October 2010 11:53, John Tapsell <johnflux at gmail.com> wrote:
> >> > On 31 October 2010 11:33, Mark Kretschmann <kretschmann at kde.org> wrote:
> >> >> Hey all,
> >> >> 
> >> >> after reading the whole thread that started with Chani's mail ("why
> >> >> kdelibs?"), I think the noise level has become a bit too much there.
> >> >> Cornelius had proposed this rather daring idea:
> >> >> 
> >> >> http://lists.kde.org/?l=kde-core-devel&m=128842761708404&w=2
> >> > 
> >> > Sounds great.  This should probably be done by picking a specific
> >> > technology in KDE, and adapting it and merging it to work in Qt.
> >> > 
> >> > A wonderful place to start would be kioslaves imho.  This is something
> >> > which has a real advantage, is relatively self-contained, and would
> >> > provide a big advantage.  Possibly it needs to be merged more with the
> >> > Qt API though.
> >> 
> >> So, if we decided that we wanted to merge KIO slaves into Qt, what
> >> would the steps we go through be? If we're going to be doing this with
> >> a number of classes we need to have a process which ensures that the
> >> code is Qute enough, KDE still compiles against it (with minimal/no
> >> code changes) etc.
> > 
> > With my packager hat on:
> > 
> > But what happens when you (KDE) decide that you really need a new feature
> > of kioslaves for the next release. But the next Qt release is not due in
> > 7 months or you (again) have trouble merging changes back to Qt with
> > patience running out? Sure, developers compiling from source can patch
> > Qt, install differently configured builds to different prefixes
> > with/without specific features etc. But what are poor packagers supposed
> > to do? Phonon situation all over again? It was *really* bad and my mind
> > is still recovering from that experience. I really doubt I'm ever going
> > to trust such merges to Qt again.
> > 
> > In my opinion, KDE should keep libraries small, *modular* and develop
> > them in- house. Try not to attach binaries and esp. daemons to the
> > libraries. Maybe strip KDE branding from library names to gain wider
> > acceptance. Only this way you as a project will be in control of release
> > schedules and feature sets.
> 
> Basically, what you're suggesting is to move as much (well, within
> reason of course) of kdelibs 'upstream' into kdesupport. I think I
> agree that this could be the way to go (at least for the short/medium
> term).
> 
> It doesn't solve our BIC/SIC problem (unless as I asked before: does
> moving the real code out into kdesupport and keeping wrapper classes
> in kdelibs solve either of those?) so we'd still need to make this a
> KDE5 thing. Or would we just have to make it libkdecore.so.6 bump
> while keeping KDE Platform/SC at version 4? It would be breaking our
> BC promise but maybe we could get away with it? :)

I am not sure but I don't see why this should cause problems, as long as the 
versions in kdesupport are in a different namespace or use a different naming. 
And as all (sic?) the clases in kdelibs use d-ptrs this should in my 
uneducated  opinion just work.

Still having wrappers for everything would be a lot of work. Who would 
maintain something like that? I mean imagine fowarding one signal was 
forgotten, what mess this could cause, even if a lot of unitests were written 
I doubt this would work flawless.

So wrapper clases might appear like a nice intermediate step, but imo they 
would add more burden than help.