proposal: remove KTextEditor interface from kdelibs repository
porten at froglogic.com
Tue Feb 1 22:13:08 GMT 2011
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
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.).
More information about the kde-core-devel