proposal: remove KTextEditor interface from kdelibs repository

[Christoph Cullmann]

On Tuesday, February 01, 2011 11:11:08 am Sune Vuorela wrote:
> On 2011-02-01, Aaron J. Seigo <aseigo at kde.org> wrote:
> > --nextPart3865859.bpjpIik9D5
> > Content-Type: Text/Plain;
> > 
> >   charset="us-ascii"
> > 
> > Content-Transfer-Encoding: quoted-printable
> > 
> > On Monday, January 31, 2011, Michael Pyne wrote:
> >> On Monday, January 31, 2011 17:42:56 Aaron J. Seigo wrote:
> >> > potential caveats are that it makes it harder to build certain KDE
> >> > apps because now you need not only kdelibs, but kate. this is already
> >> > true f=
> > 
> > or
> > 
> >> > things that require libs in kde-support, kdepimlibs or kdegraphics,
> >> > though.
> >>
> >>=20
> >>
> >> This is more a package management concern, and while I do want to avoid
> > 
> > indeed; i'm hoping one or more of the packagers will chime in at some
> > point.
> 
> I have commented on the kate developers plans more than once, but people
> just seems to bring it up over and over again. But no. Nothing has
> changed in my perception of things.
> 
> So far, we as packagers have been told that applications can expect all
> plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime
> to be available, and segfault is a acceptable way of handling missing
> things.
I agree that this will lead to additional dependency to kate package for some 
modules, but is this that bad?

> 
> Application developers has made their *current* apps based on this, and
> stuff will break by moving e.g. katepart out of kdelibs.
> 
> Now KTextEditor. KTextEditor is a public library in kdelibs. This means
> that people can actually expect KTextEditor to be there when they do
> 
> find_package(KDE4 REQUIRED)
Yeah, and because of this requirement, which I can agree on, I didn't remove 
it from kdelibs, as its public API and I wanted to be SC + BC. And no, runtime 
components moving to other modules is not a SC/BC problem.

> 
> It also means that people who builds from source can do svn up / git
> pull  in kdelibs and install new requirements,make, make install and
> still have all apps working.
They never can do that. Every now and then new dependencies come up. New 
versions of virtuoso needed, new lib*, whatever. You NEVER was able to rely 
that you can just up + recompile kdelibs and be fine. Normally it not even 
compiled...

> 
> I'm unsure why we wants to break the promises we made to the rest of the
> world about the stability of our libraries.
> 
> (oh. and why should a kile/kdevelop/... user compile and install kate?)
Because it uses katepart? We could even split it up more, in more repos, like 
katepart, kate, kwrite, but given they interdepend a lot, that is even more 
hassle.

Beside, kile users won't compile it, they will use the versions shipped with 
the distro.

> 
> /Sune
>  - who as a packager will have a hard time effectively undoing this work
>    in order to *keep* the compatibility. As a packager, I actually trust
>    KDE to live up to their promises.
I still no get this problem. kdelibs adds more and more dependencies over the 
last years, same for other modules. Why is this dependency change different at 
all? It is not even a compile time dependency change...

Beside: I am grateful for your work as packager and don't want to annoy you.

But really, the whole git moving only makes sense, if stuff that is related is 
grouped. And no, beside using kdelibs stuff, katepart and co. is not really 
related. And working over 3 repositories is a hassle. (you need to clone all, 
thats slow on dialup, you need to send at most 3 patches, you need to fiddle 
with CMake to build only the kate parts, if you want only to have katepart and 
co. fresh and not all libs, ...)

I can understand that new dependencies are work, but I don't see the problem 
in comparison to other dependencies which change the whole time.

To get new contributors for Kate, it is essential, that working on it is EASY. 
And the current way is easy (http://kate-editor.org/get-it/), the old not.

Greetings
Christoph

-- 
-------------------------------------- Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234