From kde-core-devel Tue Nov 02 10:27:36 2010 From: Cornelius Schumacher Date: Tue, 02 Nov 2010 10:27:36 +0000 To: kde-core-devel Subject: Re: "Cornelius's grand plan" - Merging KDElibs into Qt Message-Id: <201011021127.36787.schumacher () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=128869374604093 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