proposal: remove KTextEditor interface from kdelibs repository

[Aaron J. Seigo]

On Tuesday, February 1, 2011, Harri Porten wrote:
> 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".

agreed; and in the case of KFileDialog, i would expect it to be classified as 
"platform target" and moved "higher" up the chain than the "dev frameworks". 
and then there is no "sideways" dep between it and anything in libkdeui: 
libkdeui would be dev framework, KFD would be platform target.

a more layered approach, iow.

the purpose of all this would be to create something that has a profile which 
3rd party developers are more likely to take up. right now "all of kdelibs" is 
too much and we're losing lots of potential developers. being able to cherry 
pick just libsolid, e.g., would be a big win. kdelibs is better than it was in 
kde3 times, but there's still some serious mashing going on between app dev 
frameworks and platform target stuff (this is an insight i first heard from 
thiago, btw; i take zero credit and/or blame for it ;)

we also need to ask ourselves how we can encourage packagers to split things 
up better so that libsolid does come in its own binary package on a system ... 
even if we include it in a larger source module. packagers do this with our 
applications already, the challenge is in the sorts of things that sune is 
bringing up .. and much of that is our policy (or lack thereof) surrounding 
what "kdelibs" means and what implicit guarantees are provided to apps built 
using it.

> 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.).

yeah, that could definitely be part of the solution to teasing out the runtime 
dependencies ... 

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110201/b8d4869a/attachment.sig>