proposal: remove KTextEditor interface from kdelibs repository

[Alexander Neundorf]

On Wednesday 09 February 2011, Stephen Kelly wrote:
> Aaron J. Seigo wrote:
> > 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 ;)
>
> There is a wiki page for this stuff by the way. Feel free to review it or
> add to it.
>
> http://techbase.kde.org/Projects/KDELibsModifications

From the page:

TODO    kdelibs    Merge kdesupport(which is all functional libraries) into 
kdelibs

Sounds good. But kdesupport is not what it once was, stuff has been moved out 
of it, e.g. phonon.
There are also other nice Qt-addon libraries, like probably most prominently 
Qwt (http://qwt.sourceforge.net) or maybe also Qxt 
(http://dev.libqxt.org/libqxt/wiki/Home).
Having a set of non-platform, basically Qt-extension libraries, like stuff in 
kdesupport is, is not too different from those.
Maybe we could invite them (Qwt) to become part of the "KDE-powered Qt 
extension libraries" ?

Alex