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

Michael Jansen kde at michael-jansen.biz
Mon Nov 1 08:39:56 GMT 2010

> it could work out great, it could be a disaster, it could be a lot of work
> for a little gain ... we just can't tell right now because it's nothing
> more than a vague idea.
> you really can't plan the future of core assets like that.

But preparing our our assets in a way that would make identifiying and merging 
stuff into qt easy would benefit our visibility even if the merging never 

For me the biggest obstacle for anyone thinking about using kdelibs is the 
uncertaincy what that means. Currently using kdelibs and depending on the full 
kde runtime environment looks like the same.

So i think organizing kdelibs according to the 4 categories i outlined would 
help us getting our libs more into the focus of qt developers that for some 
reasons (do not want/can not) depend on the full kde runtime environment.

They could cherry pick the level of integration they want to have with kde by 
choosing up to what level of kde libs they use.

And if you combine my categorization with stephen kellys tiers model it would 
be even possible to put some interfaces into the kde look&feel category that 
has two implementations:

One default implemenetation in that category that does nothing or some 
sensible default and another implementation in the kde full runtime enviroment 
lib that plugs the app into the full kde experience if the runtime environment 
is present.

Nothing of this requires nokia to cooperate. We only would gain knowledge 
about what kdelibs is. Which would in turn open the possibility to address 
some of the "supposed" biggest problems with kde: "I only want app xyz and end 
up with one million process and one thousand databases running."

The question is if anyone would be willing to do the work. Because it is not 
sexy nor fun and would require a (probably source and feature compatible) kde 


More information about the kde-core-devel mailing list