proposal: remove KTextEditor interface from kdelibs repository

[Stephen Kelly]

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.

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.

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?