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

Cornelius Schumacher schumacher at kde.org
Tue Nov 2 10:27:36 GMT 2010


On Monday 01 November 2010 Aaron J. Seigo wrote:
> 
> we should not delude ourselves there, because if we decide to pursue such a
> course of action we need to not do so with the expectation that our need to
> work on libraries will suddenly evaporate or significantly lessen in some
> way.

Yes. The idea is not about getting rid of KDE libraries and moving everything 
to "Qt-only". That would lessen work, but it would also destroy the base of 
our technology and possibly out community. That's obviously not what we want.

The idea is about maintaining the KDE libraries in a different way, merged 
with Qt. So it wouldn't mean less work (well, maybe there could be some 
redundancies removed and free up some resources), but doing the work in a 
different way, more consistent with how it's done in Qt, more consistent for 
developers who would like to use the libraries.

> as for MeeGo as the aims there, i don't think there is nearly the overlap
> between MeeGo's goals and the goals of kdelibs that Cornelius seems to
> perceive. MeeGo is very specific and very pragmatic about caring about one
> specific platform. i've seen the result of that first hand, and it isn't
> something i see as being particularly healthy for generic libraries that
> come under its umbrella since product release schedules and "it needs to
> work for our consumer electronic product" trumps all.

I didn't say much about the goals of MeeGo compared to kdelibs. What I said is 
that for MeeGo the Qt APIs get more broad, covering a wider range of usage 
than before. While not necessarily in content, in concept this is similar to 
what KDE needs, APIs covering more than just the basic functionality of a UI 
toolkit, which is used by everybody.

For example the idea to create something like QtDesktop similar to QtMobility 
is neat. That would go into this direction. It of course needs a lot more 
investigation and concrete details to tell, if it makes sense.

> imho Qt open governance is mature enough yet to realistically support free

I suppose you meant "is *not* mature enough yet".

> handed 3rd party involvement in development. when we (KDE) would need
> something, it would result in a lot of asking Qt Dev Frameworks for
> permission and convincing of others. right now, that's unlikely ime, and
> when things are improved (and i do think they will) it will be less
> efficient than what we have now due to the increased number of entities
> involved.

That's a challenge for the Qt community and the people steering it. It won't 
be easy, but things are improving, and I deeply hope that they are really 
successful with building up a community which makes it easy to participate and 
contribute. To what degree we in KDE want to be part of that, is up to us. We 
have a lot to contribute, in technical terms as well as in community terms.

> so what exactly do people mean when talking about "merging with Qt"? not
> broad brush strokes, but specific detailed goals.

Yes, and I'm happy to see how many good ideas and details already have been 
produced in this thread.

> you really can't plan the future of core assets like that.

I don't think we can talk about a plan yet. This started as brainstorming and 
some ideas, and an idea for something like a big hairy goal. I would love to 
see this evolve into an actual plan for the future, but there certainly is a 
lot of work ahead, before we are there.

-- 
Cornelius Schumacher <schumacher at kde.org>




More information about the kde-core-devel mailing list