> In Bug 153463 [1], 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
> kdesdk/kompare.

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 
as before.

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.

        Kevin Kofler
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team