proposal: remove KTextEditor interface from kdelibs repository

[Alexander Neundorf]

On Wednesday 09 February 2011, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > 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" ?
>
> From a thread linked in the page :) :
> > Benjamin and I were in the qxt channel to see what kind of stuff
> > they have, how it's licenced, and organized etc. It's not clear yet if
> > that would be a good place to put classes like these. Personally, I'd
> > prefer something tied to the kde release schedule. I'm not sure the qxt
> > guys would go for that though.

Ooops, sorry, didn't see that. Actually I heard from Qxt the first time just a 
few weeks ago.

> Things have changed, as you said. I'm all for making something more
> inclusive of the existing community of extensions to Qt if that's possible.
> Evaluating whether some kde libraries can be made Qt only without kde
> interdependencies needs to happen first though I think.

Yes. One question is where to draw a line.
E.g. for me (speaking as commercial developer) I'd be fine to have to link a 
few more libraries, as long as they don't require to run some extra daemons 
or something. So if there was some library which depends on Qt and some 
library from the KDE non-platformy libs this would probbaly be fine with me.
IOW, I wouldn't want to have to start virtuoso to use some graphing widget ;-)

> Qxt may also have the same problem KDE has.
>
> http://libqxt.bitbucket.org/doc/tip/qxtapplication.html
>
> Do you have to use a QxtApplication to use some features of Qxt? Is that at
> odds with KApplication? I have no idea. Does Qwt have something similar?

No, Qwt is really just a set of widgets.

Alex