proposal: remove KTextEditor interface from kdelibs repository
Aaron J. Seigo
aseigo at kde.org
Tue Feb 1 21:48:35 GMT 2011
On Tuesday, February 1, 2011, Maksim Orlovich wrote:
> On 2/1/11, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 01.02.11 19:49:10, Albert Astals Cid wrote:
> > No, the natural fix is to make the dependency chain proper, i.e. KTE
> > depends on kdelibs, khtml depends on KTE+kdelibs. That means khtml
> > cannot be part of kdelibs anymore if KTE is not part of kdelibs anymore.
> Funny, I would think the proper fix would be for people who put their
> work into kdelibs to honor the requisite commitment to backwards
> compatibility, rather than to punish other
> libraries for doing the right thing in using existing facilities.
it's not about punishing any library or individuals' work. if we modularize
kdelibs, then that means we may end up with a small set of interconnected
repositories with clear dependency chains. for instance...
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. we may even decide to split
things up into "dev framework" vs "platform target". (if this sounds like
"KDE5" sort of stuff .. well .. yes :)
then we'd have other pieces that have been put into kdelibs in the past that
maybe should live on as part of the KDE Platform (or whatever call it) but in
their own repositories. that could include the KTextEditor interface, perhaps
libplasma as well.
so in the case of something that uses KTextEditor and is part of kdelibs now,
it could still be part of the KDE Platform but be its own module with a dep on
corelibs+kate. which is really no different than it is right now, except
everything would be explicit and not in one single repository.
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
the domino effect there would be altering CMakeLists.txt for apps that need
KTextEditor (for example) to explicitly include it. alternatively, we could
maintain a compatibility FindKDE4-style macro that would pull in all those
pieces. so apps that did nothing would still have the same build profile
without any modifications, just risk pulling in more libraries than they
really need as build requirements. a "virtual" kdelibs if you will. we sort of
have this already with kde-support, imho.
apps could then be updated as desired to more accurately note their needs,
bringing dependency definition into sharper definition. but most importantly,
new apps, or existing Qt apps, could then much more easily say "I just want
libkdecore" or "I just want libsolid" and get it.
there are a hell of a lot of details in between all those broad strokes. if we
start pondering them now, though, by the time we hit Randa in June we may be
in a very good position to have effective discussions that result in actual
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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel