"Cornelius's grand plan" - Merging KDElibs into Qt
torsten at kde.org
Sun Oct 31 13:37:54 GMT 2010
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
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,
- 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
More information about the kde-core-devel