[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: proposal: remove KTextEditor interface from kdelibs repository
From:       Harri Porten <porten () froglogic ! com>
Date:       2011-02-01 22:13:08
Message-ID: alpine.DEB.2.00.1102012259260.1582 () greco ! froglogic ! com
[Download RAW message or body]

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.
[prev in list] [next in list] [prev in thread] [next in thread]