What to do about Kompare?
kevin.kofler at chello.at
Tue Dec 11 00:04:16 CET 2007
> In Bug 153463 , Kevin Kofler provides some patches to make the current
> Kompare code in kdesk compile (and work, I guess).
It definitely works here, at the very least. :-)
> I haven't tested the patches myself. In the past few days he even provides
> patches to forward port stuff from the 3-way-kompare branch to
To clarify what I ported and why: I ported the reworked KompareSplitter from
3_way_kompare to trunk (not sure whether to call it forward, backward or
sideward porting ;-) ) because the trunk was using horrible hacks to
QSplitter which were 1. ugly and 2. didn't work with the Qt 4 implementation,
so I had to port the Qt 3 QSplitter implementation and drag in a private Qt
header needed by that. The 3_way_kompare branch has a clean solution based on
the Qt 4 QSplitter, which now has the required feature (custom splitter
handles) to make the KompareSplitter work. So by porting that clean
implementation, I was able to throw the hacks out, there's no private forks
of Qt code nor private Qt headers/functions used anymore and it still works
I'm also considering porting KompareProcess from 3_way_kompare to trunk
because the version in 3_way_kompare uses QProcess, the version in trunk is
stuck with K3Process which is *nix-only. That should be an even smaller
change than KompareSplitter, but I haven't looked into it yet.
I'm not planning to port any other stuff from 3_way_kompare for 4.0.
Cleaning up the half-finished features in 3_way_kompare, and also porting some
of the changes to the trunk which were never merged to the branch, will be a
bigger task, but that's for 4.1 at the earliest.
> Kevin, would you want to take over kdesdk/kompare and make it work for
> KDE4.0.0? Else, I guess we won't have kompare in KDE4.0.
Yes, I'm willing to pick it up.
More information about the release-team