Clarification on a VCS-Iface Issue

[Andreas Pakulat]

On 03.09.07 21:51:39, Matt Rogers wrote:
> On Sep 3, 2007, at 6:24 PM, Andreas Pakulat wrote:
> > to those of you that were involved in the Vcs-Iface Design decisions
> > (and all others as well of course :):
> >
> > Did we decide that the actions like commit, add, copy, move (the
> > non-Show-versions) have to work without _any_ gui at all, or are they
> > allowed to popup dialogs when they need input like authentication
> > information, or say a commit message (as import for example misses a
> > commit message argument)?
> >
> > I'm not sure wether we discussed this at all and having had a look at
> > the svn plugin its clear that we need a decision. I don't think it  
> > makes
> > sense to restrict these actions to non-gui-mode, as then they'd  
> > have to
> > fail and they can't be executed without some sort of GUI running  
> > anyway.
> >
> > If we decide this I'll put a clear doc about the difference between
> > showwXXX and XXX into the api docs. Currently I'm leaning towards
> > something along the lines (assuming we allow gui from XXX methods):
> >
> > showXXX - allows the user to input the parameters for the action to be
> > executed, always shows this GUI
> >
> > XXX - tries to execute the action without user-interaction, but will
> > create a dialog if needed for input of missing information
> >
> > Andreas
> 
> This is where I dislike having two different sets of API that perform  
> the same thing. It was said that this is for scriptability. However,  
> doesn't a platform app have to be running to be able to run scripts  
> anyways. Why can't we just normalize it so that it does what you  
> suggest in the XXX case and remove the showXXX versions of the same  
> functions?

I was about to agree with you, but then I remembered why we added the
showXX methods in the first place: To make it possible to retrieve the
result from the action, instead of displaying it to the user. This of
course doesn't make sense for all actions, for example
add/remove/move/copy/commit and possibly others. But for things like
stat(), diff() and maybe a few others this is a real good thing, because
those can then be used from other parts of KDevelop, for example the
project tree can ask the project wether it has VCS and then just ask the
VCS for status of all the dirs/files.

So how about removing the showXXX methods where it doesn't make sense,
i.e. the result/return value of the job is trivial and leave it in for
others, along with my suggestion above, that any XXX/showXXX method is
allowed to ask for needed parameters.

Andreas

-- 
Your goose is cooked.
(Your current chick is burned up too!)