proposal: remove KTextEditor interface from kdelibs repository

[Harri Porten]

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.