"Cornelius's grand plan" - Merging KDElibs into Qt
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
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