unifying libdiff2

Jeremy Whiting jpwhiting at kde.org
Fri Oct 28 00:14:43 UTC 2011


hey all,

Sorry for cross-posting, I'm not sure who is on which list.  We can
continue this discussion on one or the other, but I wanted anyone
interested to be able to chime in.

As you may or may not know, libdiff2 is used in kdesdk/kompare and
kdevelop/kdevplatform/plugins/patchreview (one is a fork/copy of the
other).  I'd like to bring these back together into one library that
is exported like a real library so both places can use it.  Where it
lives is still up for debate, but probably kdelibs or kdesupport or
something.  So I looked at what is different between the two copies
and found some very minimal differences.  Most I figured out which was
newer and incorporated that into both copies on my machine, but there
are some logic differences I wanted to ask about.

In komparemodellist.cpp saveDestination the version in kdesdk checks
for opening a file and emits an error if it can't open.  Curiously the
version in kdevelop does the opposite, it sends an error if it is able
to open the file.  My only guess is that this code is not used in the
kdevelop patchreview code.  If anyone knows why it is the way it is in
kdevelop copy I'd like to hear otherwise I'll use the version from
kdesdk.  Towards the end of that method in the kdevelop version it has
an if false where in the kdesdk version it checks for a temp close
error, not sure why.

Similarly in the kompare version of komparemodellist.cpp there are a
bunch of actions in the ctor that are just commented out in the
kdevelop version.  Maybe komparemodellist should move out of libdiff2
and into kompare itself?  Alternatively we could check at runtime if
our parent is a KomparePart and initialize the actions only then, so
kdevelop could still use the model.

One final difference is that the kompare version has the idea of a
malformed patch and keeps track of that throughout komparemodellist,
parser, and parserbase.  My instinct is to take the kdesdk version as
that seems like an addition.

comments on any of the above are welcome.

thanks,
Jeremy Whiting




More information about the KDevelop-devel mailing list