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

[Torsten Rahn]

Am Sonntag, 31. Oktober 2010 12:33:22 schrieb Mark Kretschmann:
> It's a very controversial idea. However, I think it is so refreshing
> that it deserves some more thought. Personally, I think the idea is
> great, if we can overcome some of the obvious road blocks. I would
> love to read some honest and direct thoughts from you guys.
> What do you think about it?

Actually it's quite funny: At the openSUSE conference party I had asked 
Cornelius a question that was very similar to the one Chani was asking. And I 
was positively shocked about Cornelius' answer which was back then very much 
along the lines of his "grand plan". 

Qt and the Qt landscape has changed dramatically through the last 2 years. 
Devices, platforms and technologies have converged rapidly.  And while KDE 4.x 
is a concept that works nicely right now (and will surely still do at least 
for the next 2-3 years) we need to ensure that we stay competitive. And we 
need to help ensuring that the Qt ecosystem doesn't fragment into lots of 
toolkits and libraries that don't unnecessarily reinvent wheels over and over 
again.
 
This requires an open mindset which allows to reevaluate and question 
everything KDE. I'm positively surprised to see so many KDE people here being 
open for dramatic changes.  And of course I also like that there are lots of 
careful reality-grounded people as well since we need a good balance between 
being creative and realistic.

So here are a few thoughts of mine about this topic:

 * I think a good start would be if we defined better acceptance criteria for 
stuff that gets accepted into kdelibs. 

Right now I have the impression that basically everything gets in as long as 
it could possibly have a slight benefit in some situations. The result of this 
is that an application developer gets the exotic nice-to-have feature (that he 
could easily reinvent in no time himself if it wasn't available). but he also 
has to swallow the thousands of others nice-to-have features which are of no 
use to him. 
In this light I think the 80% rule for Qt is a pretty good thing - at least 
for Qt's core: It keeps the core on diet and makes it still 

- easy to keep an overview over the available class set
- and easy to learn Qt.

 * We better need to identify the purpose of KDElibs features: Who benefits 
from them? At which expense?  What is the penalty?

The KDE library not only extends the feature-set of Qt. 
It also serves different purposes: 
- Some of the stuff inside kdelibs only has a benefit for the KDE project 
itself to ease maintenance across several applications. That's something that 
certainly doesn't really belong into Qt.  Even worse would be APIs that would 
just exist to model our project processes - but I don't think we have those, 
do we? 

- Other stuff  is largely tied to the paradigm of a desktop. Which brings me 
to the thought:  Let's start at what we good at: Let's start creating and 
maintaining a "Qt Desktop" module which would provide building blocks that are 
specific to the "classical" desktop. I guess that could be "our" initial sweet 
spot  which could complement the "Qt Mobility" module nicely.


I had similar ideas already cooking in my head during the last few days for 
Marble and that is also the reason why for the Marble Sprint I had the idea of 
putting the Marble Sprint under the topic of "Let's be open to reinvent 
ourselves."

Best Regards,

Torsten