<br><br><div class="gmail_quote">On Thu, Aug 6, 2009 at 8:43 AM, David Nolden <span dir="ltr"><<a href="mailto:david.nolden.kdevelop@art-master.de">david.nolden.kdevelop@art-master.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Am Mittwoch 05 August 2009 22:03:13 schrieb Andreas Pakulat:<br>
<div class="im">> > By annotated in this case, I mean having highlighted all changed hunks in<br>
> > the code, and allowing to jump between, edit them directly, and reverting<br>
> > them with a click. Essentially the same thing you can do with kompare,<br>
> > except that we would have code-highlighting, -editing, and all the bling.<br>
><br>
> Ideally yes, but that'll take some serious amount of work and time.<br>
><br>
> > Most of the required code is already in the teamwork plugin,<br>
><br>
> Yeah, unmaintained for more than a year now, no thanks I think.<br>
> Especially since that would mean having to extract it from there, check<br>
> wether the difflib still is up-to-date, having a conflicting library<br>
> with kompare etc... I'd rather have kompare extended to allow in-place<br>
> editing if you ask me. That one is at least properly maintained and we<br>
> don't have to do all the dirty work ourselves.<br>
</div>I've already extracted it here locally, and I'm building a toolview out of it<br>
that can take an arbitrary _applied_ patch, highlight it in the code, and<br>
allow jumping between it.<br>
<br>
It should be ready in a few days in a nice state if I find time for it again.<br>
It isn't much work.<br>
<br>
Given all the problems you guys are facing with embedding kompare, the<br>
question arises, why do we even want to _embed_ kompare? Wouldn't it be<br>
perfectly ok to by default highlight the changed code directly within kate<br>
text editors using that toolview, and having a button in that toolview to<br>
launch kompare in a separate window on the diff?<br></blockquote><div> We're working on an IDE, we want something integrated. It would be good but... we can do better.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
As the main advantage I see in kompare is that it can outline the changes in a<br>
compact way, that way we would have a logical split of functionality.<br>
</blockquote><div>Plus we don't maintain it.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
As to improving kompare: Even if the patch was fully editable within it, we<br>
still wouldn't have semantic- and syntax-highlighting there, and also no code<br>
completion. So, especially if the kompare part was embedded, this would lead<br>
to an inconsistent editing experience.<br>
</blockquote><div>I don't think it would be inconsistent, even if the semantic stuff is useful, it's just fine to read the code when reviewing.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Greetings, David<br>
<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br>So are you planning to get this to work? if you do I won't keep working on that, I don't want 2 conflicting patches. I can let you work on that if you wish, and we see what happens.<br>
<br>Thanks,<br>Aleix<br>