Clarification on a VCS-Iface Issue

[Matt Rogers]

On Wednesday 05 September 2007 04:02, Andreas Pakulat wrote:
> On 04.09.07 21:04:23, Matt Rogers wrote:
> > On Sep 4, 2007, at 8:14 PM, Andreas Pakulat wrote:
> > > On 04.09.07 18:54:34, Matt Rogers wrote:
> > >> We should always retrieve a result. Don't we always need to know
> > >> whether something succeeded or not? Whether or not we display it to
> > >> the user is up to the user of the API. We need to remove all of the
> > >> showXXX methods. They're redundant.
> > >
> > > I don't think they are. Those are specifically to let the user see
> > > the result
> > > instead of just fetching it and eventually doing something with it.
> > > For
> > > cases where the user of the API wants the developer see the result of
> > > the diff, the showXXX methods can be used, which saves the user of the
> > > API some code to write that would put the diff into a diff-viewer.
> > > This
> > > code would be redundant for _every_ user of the API that wants to show
> > > the diff to the user and that redundancy is avoided by having showXXX
> > > methods.
> >
> > Ok, so diff is a valid use case for these show methods. Perhaps we
> > can rename them displayXXX instead? Do you have other valid use-cases
> > for other methods? Diff is the only one where I am aware of where it
> > makes sense. Perhaps log as well.
>
> I'll go through the interfaces tonight and come up with a list.
>
> > Another idea:
> > What about just having the XXX methods in most cases displaying these
> > things in a tab in the text editor? We provide a virtual protected
> > function that allows the user of the API to customize how the display
> > is handled, and the XXX function calls it. This is similar to how
> > it's handled in QItemDelegate and that's basically the same sort of
> > functionality we're talking about here.
>
> I think I don't really follow you. How can the user of the API provide a
> function to customize the display when the versioning interface has no
> idea about the user? Its currently a one-way-API, a user can call a
> function from the Vcs API but the Vcs API doesn't know anything about
> the user (wether its a script, a class from shell, or another plugin). I
> think I need a bit more detail on this to understand.
>

If you look at the docs for QItemDelegate, you can see it provides four 
virtual functions for customizing the drawing. Reading the source, 
QItemDelegate's paint() call calls each one of those virtual functions, 
allowing the developer deriving from QItemDelegate to provide their own 
custom drawing mechanism if they so choose. Most of the time though, it's not 
needed, but the flexibility is there.  

We'd be doing the same sort of thing here.

Example: 

We have a diff() function that calls some "virtual void displayDiff()" 
function, which, wherever it gets implemented, does something we want it to 
do. Continuing with the above example, it'd open a new tab in KDevelop with 
the output of the diff command as the text. the displayDiff function could be 
overridden as needed to customize how the output is displayed.

Does this explanation provide enough detail or did I leave something out?
-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070905/1f5786e9/attachment.sig>