unifying libdiff2

Bruggeman, Otto G otto.g.bruggeman at intel.com
Fri Jul 12 09:36:22 UTC 2013


Sorry outlook here at work. Trying to fake some sane formatting...

Kevin Kofler (KK) wrote: 

On Thursday 11 July 2013 at 20:18:37, Jeremy Whiting wrote:
> 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.

KK> +1, makes sense.

OB> Yes full ack, this is how it was meant to be. Never found the time to finish this.
OB> I also wanted to find a way to interface with the diff code directly so I would 
OB> not have to parse the diff output and use the internal representation of diff :( 
OB> If only there were 100 hours per day and I would only need 8 hours sleep...

> 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?

KK> Yes, that dependency also needs to go away. I'm fine with whatever change is made 
KK> to make it unnecessary (as long as it doesn't break Kompare, of course).

OB> The isReadWrite is determined when the Part is instantiated and does not change 
OB> during the lifetime of a Part if I understood this correctly back in the KDE3 days. 
OB> Not sure if this changed during KDE4 and later versions. David Faure would be able 
OB> to tell without any doubt whether my recollection is right.

> thoughts, questions, etc. if not I'll make these changes and put up a 
> review request.

KK> Go ahead. I agree with the ideas in principle, I'll review the implementation on 
KK> ReviewBoard. (I expect it will be fine, but I'd still like to see the code 
KK> before it goes in.)


Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052



More information about the KDevelop-devel mailing list