> 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 happens. 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 5. Mike
