<div dir="ltr">Ok, it looks like the kdevplatform copy of libdiff gets around needing diffsettings by copying diffsettings.h|cpp and settingsbase.h|cpp also. Which makes me wonder if that ought to just be part of libdiff2 and kompare's libdialogchanges could get it from libdiff2 itself rather than owning those classes and code. <div>
<br></div><div>The other difference and dependency of libdiff2 is kompare_part.h used in komparemodellist.cpp to get the actions from the action collection (can't this be done without casting the parent to komparePart though?) and to get isReadWrite from the parent. Maybe isReadWrite should be a property of the komparemodellist rather than the kompare part? Then when the kompare part isReadWrite changes, it just changes it on it's modellist also?</div>
<div><br></div><div>thoughts, questions, etc. if not I'll make these changes and put up a review request.</div><div><br></div><div>thanks,</div><div>Jeremy</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Jul 11, 2013 at 7:05 PM, Jeremy Whiting <span dir="ltr"><<a href="mailto:jpwhiting@kde.org" target="_blank">jpwhiting@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Step 1 is complete more or less. I have created libdiff2 git repo (currently at scratch/whiting/libdiff2.git) by taking kompare and doing the following (documenting here since I'll likely need to repeat these steps at some point)<div>
git checkout -b KDE/X.Y origin/KDE/X.Y for all branches.<br><div>git filter-branch --subdirectory-filter libdiff2 --tag-name-filter cat -- --all</div><div>then cloning the result with file:/// url to not get the unused objects.</div>
</div><div><br></div><div>The result is a libdiff2 git repo that only has libdiff2 changes and files. It includes all tags and branches, however it doesn't build. There's currently code in libdiff2 that wants files from other libraries in kompare (diffsettings.h, kompare_part.h, etc.) These will need to be removed but I'd like input from kompare developers on how this should happen before I make any changes.</div>
<div><br></div><div>thanks,</div><div>Jeremy</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 10, 2013 at 3:39 AM, Aleix Pol <span dir="ltr"><<a href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>On Wed, Jul 10, 2013 at 7:31 AM, Jeremy Whiting <span dir="ltr"><<a href="mailto:jpwhiting@kde.org" target="_blank">jpwhiting@kde.org</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hello all,<div><br></div><div>Since kdesdk has now safely migrated from svn to git, I thought it would be a good time to get this ball rolling again. I just reread this thread and would like to suggest the following:</div>
<div><br></div><div>1. Move libdiff2 out of kompare.git into it's own git repository just within kdesdk on <a href="http://projects.kde.org" target="_blank">projects.kde.org</a></div><div>2. Make sure libdiff2 installs header files and CMakeConfig file, etc. so it can be easily used by kompare, okteta, kdevplatform patchreview plugin, and anything else that wants to use it. (Not sure if this is already the case, Kevin or Konstantin, you guys would know better, or I can investigate)</div>
<div>3. Make kdevplatform patchreview plugin use the new libdiff2 that has everything properly exposed.</div><div>4. Review the difference between the two copies of libdiff2 to see if any changes in the kdevplatform copy should be merged into the main one in kdesdk</div>
<div>And lastly, nuke the libdiff2 folder in kdevplatform.git</div><div><br></div><div>Suggestions, questions, or answers to any of the above welcome.</div><div><br></div><div>thanks,</div><div>Jeremy</div></div><div>
<div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Dec 11, 2011 at 2:54 PM, Aleix Pol <span dir="ltr"><<a href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Jeremy,<div>What's the status on this one?</div><span><font color="#888888"><div><br></div></font></span><div><span><font color="#888888">Aleix</font></span><div><br><br><div class="gmail_quote">
On Sat, Oct 29, 2011 at 5:35 PM, David Nolden <span dir="ltr"><<a href="mailto:david.nolden.kdevelop@art-master.de" target="_blank">david.nolden.kdevelop@art-master.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I was the one who once forked libdiff2 many years ago (probably around<br>
2007 or so), and it was mainly for comfort reasons, because libdiff2<br>
would have needed a quite big refactoring to be nicely usable by both<br>
Kompare and KDevelop:<br>
* libdiff2 was a static library living in a subdirectory of the at<br>
that time unmaintained kde4 kompare port<br>
* libdiff2 contained a lot of UI code, while we were only interested<br>
in the 'model' code (that's why I commented out quite a bit of stuff)<br>
<br>
While it is nice to share some code, I'm also not in favor of adding<br>
huge dependencies like 'whole kdesk'.<br>
<br>
Having the code shared can also make life significantly harder<br>
regarding changes in the library: How should the correct versions of<br>
the library and the application be synced together? We experience this<br>
again and again through the split between kate and kdevelop. Therefore<br>
we should ask the question whether KDevelop and Kompare really have so<br>
much in common, that they will actually _profit_ from each others<br>
potential future improvements in a shared libdiff2. The word 'fork' is<br>
often interpreted more evil than it actually is. ;-)<br>
<br>
Greetings, David<br>
</blockquote></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div><div class="gmail_extra"><div><div class="gmail_extra" style="font-family:arial,sans-serif;font-size:13px">Hi,</div><div class="gmail_extra" style="font-family:arial,sans-serif;font-size:13px">
As I've said before, I'd welcome such merge. I'm mostly concerned with losing features or introducing new bugs, we should make sure that this doesn't happen.</div><div class="gmail_extra" style="font-family:arial,sans-serif;font-size:13px">
<br></div><div class="gmail_extra" style="font-family:arial,sans-serif;font-size:13px">Additionally, if the library can be split between Core and Gui (for example :D) it could also be helpful, but we can review this further in the future, when the library is in place.</div>
<div class="gmail_extra" style="font-family:arial,sans-serif;font-size:13px"><br></div><div class="gmail_extra" style="font-family:arial,sans-serif;font-size:13px">Thanks Jeremy!</div><div class="gmail_extra" style="font-family:arial,sans-serif;font-size:13px">
Aleix</div><div class="gmail_extra" style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div class="gmail_extra" style="font-family:arial,sans-serif;font-size:13px">PS: Sent again because the e-mail for the kdevelop mailing list was outdated.</div>
</div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>