"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