proposal: remove KTextEditor interface from kdelibs repository

[Aaron J. Seigo]

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 
is now.

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 
decisions :)

-- 
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/17b63f6a/attachment.sig>