unifying libdiff2

[Jeremy Whiting]

Kevin,

Thanks for the guidance.  I did decide the actions and such do belong
inside KompareModelList afterall, and found a way to make KomparePart get
the actions from the KompareModelList and add them to it's own
actionCollection.  I've pushed a branch to kompare called movelibdiff2 if
you want to take a look.  It works ok here, but I'll let you guys see what
you think of my solution.

My libdiff2 is at scratch/whiting/libdiff2 and builds by itself and
installs a LibKompareDiff2Config.cmake file that libdialogpages on my
branch uses to find LibKompareDiff2 variables to build against.

thanks,
Jeremy


On Thu, Jul 18, 2013 at 5:05 PM, Kevin Kofler <kevin.kofler at chello.at>wrote:

> On Thursday 18 July 2013 at 14:04:52, Jeremy Whiting wrote:
> > One other question, do we want the library to be called libdiff2 as the
> > directory is named? or libkomparediff2 as the .so is named?  I'd like to
> > make them match, so I'd change one or the other to make them match.
>
> I'd go with libkomparediff2. (libdiff2 is too generic, it'd make sense if
> this
> were a really general diff library without any KDE dependencies and used by
> many diffing apps, but that's not what this library is.)
>
> (As for your other question, I'm going to defer the answer until we know
> whether option A is even implementable, as per your followup. If not,
> there's
> no decision to be made there. ;-) )
>
>         Kevin Kofler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kompare-devel/attachments/20130719/cd7a8e16/attachment.html>