On Tue, 1 Feb 2011, Aaron J. Seigo wrote:
we could end up with a "new kdelibs" module that contains just the core stuff such as kdecore, kdeui, kio .. there could be requirements in there about allowable dependencies between those libraries.
[...]
the big change here would be that applications that require different parts of the KDE Platform might have to define which parts to include (e.g. KTextEditor interface) rather than them being provided implicitly in one big chunk as it is now.
Would that be really such a big change? We can certainly redefine a "new kdelibs". But I think it will always be just another set where some (sometimes arbitrary boundaries) are drawn. In my eyes, KTextEditor is just a very random example. Will we next have the same discussion about KFileDialog? It uses KPushButton. Should we move out both to avoid sideways dependencies?
What I want to say: we can always define what kdelibs comprises. It can be small, it can be big. I don't see a technically perfect optimum, though. At best we can strive for "reasonable".
Unless.... unless we find some real technical means to manage compile-time and runtime-dependencies. Maybe even MS Windows can serve as an example of a platform that has gone through all of this, is very extensible and at the same time very much backward compatible? One part of the puzzle I can think of a interfaces (pure .h files) that can be queried at runtime. In one way or the other that has been excersised in KDE in the past already (Corba, KParts, DCOP/D-Bus, KService etc.).
Harri.
