Using the KomparePart in KDevelop

[Andreas Pakulat]

On 23.07.09 19:24:13, Kevin Kofler wrote:
> On Thursday 23 July 2009, Andreas Pakulat wrote:
> > Not the part, but indeed the library needs it - unless the maintainers
> > don't enforce BC during the KDE4 lifetime?
> 
> So far, the internal Kompare libraries have been in ABI Wild West, I even 
> backported ABI changes (which were part of bugfixes) to 4.2.x point releases 
> (with no soname bump). But if something outside of Kompare starts actually 
> using those libraries, that will have to change. :-(

Well, there's no real global KDE policy on that (AFAIK), though yes
packagers as well as release team appreciate stable ABI's :)
 
> I'd be pragmatic and say: as long as KDevelop is the only external user of 
> those libraries, feel free to do the changes you need on your schedule as long 
> as you update the main Kompare application at the same time (so it keeps 
> working). You do need to bump the soname if you change the ABI of a public 
> library, and there are also policies on not doing such bumps in a point 
> release (e.g. you can bump the ABI of a library in an application module like 
> kdesdk for KDE 4.n->4.n+1, but you're normally not supposed to do that for KDE 
> 4.m.n->4.m.n+1 and you may get into trouble with the KDE Release Team if you 
> try doing that; that said, distros like Fedora which plan to ship KDevelop 4 
> as soon as possible may be backporting those required API/ABI changes, we 
> already did that to kdegraphics in KDE 4.1.x for Digikam 0.10 Beta, and in 
> this case Fedora would automatically have upstream buyin to do those backports 
> because I happen to be Kompare's upstream maintainer ;-) ). Of course, the 
> more users the library gets, the more ABI compatibility gets important. (But 
> binary compatibility is not required for the entire lifetime of KDE 4 as it is 
> for kdelibs and kdepimlibs.)

Ok, as we already have a fallback for the case where kdesdk is not
available, I guess its fine to add the new virtual method to the existing
kompareinterface class (and the part of course) and just let KDevelop use
KomparePart only when KDE 4.4 or later is found. As we're currently aiming
at a release around the end of the year that won't be too much of a
problem.

BTW: I also plan to have a kdesdklibs module for KDE 4.4 because we need to
share some code+data between kdevelop and kapptemplate (and Anne-Marie
doesn't want to use kdevplatform for a simple app like kapptemplate). So
maybe we could think about moving the interface header to that module (once
it exists), so KDevelop has only a runtime dependency on kdesdk and no
(optional) compile-time dependency?
 
> Note that KParts do also have an ABI, but the encapsulation there is stronger 
> than for a regular library: not everything that's public in the class 
> implementing the KPart is actually accessible from the outside, see e.g. how 
> the KatePart selectively exports APIs.

Yeah, it shouldn't be done in a different way - IMHO. Casting a
KParts::ReadOnlyPart to lets say "KomparePart" is just evil, the part
should be able to have a public API thats only visible inside the parts
implementation.

Andreas

-- 
Go to a movie tonight.  Darkness becomes you.