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