Kompare support for patch and difference reviewing

[Andreas Pakulat]

On 05.08.09 03:46:58, Aleix Pol wrote:
> Since there are some things I'm not sure of, I'll expose them to you so that
> we can find the best solution.
> 
> My first idea was to get the Kompare part to be used as a Document.

Good idea :)

> Problems I see:
> - It's not really suitable to see the differences in places like the the
> history dialog. First of all it would show on the background and it would be
> (ideally) readonly in case none of the versions compared are the local one.
> That makes me think that having the VcsDiffWidget using just the Kompare
> part would be good (checking if one of the version is the Base would be a
> +1, but not that necessary, being able to generate a patch from that would
> be just fine).

I'm not sure I follow you here. The current history _dialog_ should
actually be a toolview. But since we've got rid of the vcscommon plugin
I haven't had time to think about or implement that :) So if you're
problem was having a dialog in front of the kompare-document, then
that'll be solved sooner (or later)...
 
> - Sublime wants us to have a URL for each of those opened documents (If I
> understood properly). Here my idea would be to have some URL like
> vcs://the/base/path?from=123;to=321 so, in other words, have the arguments
> to pass to IBVC::diff so that the document knows what information he needs.
> The other could be to have some way to pass it some VcsDiff tuple with all
> the needed stuff (like having the slot that receives that in an empty
> PatchDocument).

Hmm, I'm not sure I see the need for a special URL or any special
information. I think its sufficient to just have the filename of the
file you're diffing in the document title and the url contains the path.
We just need to make sure that for plain viewing of a diff, we make the
kompare part readonly so the user cannot save anything. And if its used
for merging conflicts then the url will be the actual local url of the
file that has the conflicts. Am I missing something?

> - The KomparePart has plenty of tool buttons, which we need for patch
> reviewing, but not all the time. Plus the tool bar is merged with the main
> one and i can't hide it when I don't need it (because i might need the rest
> of the stuff).

There's a patch on kde code list floating that would allow supplying our
own xmlgui-file for the part and hence produce our own toolbar. The
other option would be to kindly ask the kompare author if he could use a
different name for his toolbar so its not merged with our main toolbar.
The last option would be to fetch the actions from the parts action
collection and insert them with differing names into the plugins action
collection and this way making sure they end up in their own toolbar.

However I am actually not sure wether this is really needed. If we
really have a separate area thats used for this, we'll only have the
kompare actions in the toolbar and the area-switching stuff.

> Another way would be to enhance the VcsDiffWidget so that it's useful for
> all use cases. That would work, but I don't think we want to have another
> window just for that, looks workaround-ish.

No, the less dialogs, the better :)

> I'm not really used to the Ui code (as you will see from what I've said). So
> if I might have had some bad assumptions.

If you need some inspiration code-wise have a look at the designer
plugin in playground. Its not exactly the same integrating a KPart, but
at least you get an idea how to provide a custom document class and
provide the toolbars too.

Andreas

-- 
You will be aided greatly by a person whom you thought to be unimportant.