KDE/kdevelop/lib/plugins/vcs/interfaces
Matt Rogers
mattr at kde.org
Thu May 31 20:20:42 UTC 2007
On Thursday 31 May 2007 14:58, Andreas Pakulat wrote:
> On 31.05.07 14:32:16, Matt Rogers wrote:
> > On Tuesday 29 May 2007 11:32, Matthew Woehlke wrote:
> > > (I tried to reply to your commit log but don't see the message yet...
> > > might be moderated or blocked because I sent from a different address.
> > > So apologies if it shows up later and duplicates this :-).)
> > >
> > > Andreas Pakulat wrote:
> > > > On 27.05.07 21:04:33, Matt Rogers wrote:
> > > >> On Sunday 27 May 2007 20:53, Andreas Pakulat wrote:
> > > >>> SVN commit 668891 by apaku:
> > > >>>
> > > >>> add exec() which runs the job in a synchronous way
> > > >>
> > > >> Why? Under what circumstances would we need the synchronous way of
> > > >> doing things?
> > > >
> > > > For simple scripts for example, those don't have signal/slot stuff
> > > > set up necessarily.
> > >
> > > Right. Btw, whatever happened to wait()? Should we have exec(), wait()
> > > or both? (Note: exec() == start()+wait() if we have wait().)
> > >
> > > To answer Matt: scripts generally run sequentially, it is I think much
> > > easier to write a script that way than to all the time tie the
> > > finished() signal to starting the next step of the script.
> >
> > How bout for right now we don't care about scripts and instead focus on
> > actually making a usable IDE? If somebody is using the IDE, why would
> > they write scripts?
>
> Because they want to automate tasks, also look at the recent wishlist
> report about "open foo.cpp" and have it show up in KDevelop.
>
> Andreas
My objection is that we have no one using this functionality already and it
overlaps with already existing functionality (aka command line clients). It
seems like we're just adding it because we think it would be cool. If people
want to write scripts to interact with version control systems, they should
use the command line version of said version control system. The only version
control system that doesn't have an command line version is Visual SourceSafe
and I don't want to support that from within KDevelop anyways.
Since we are dealing with interfaces, we don't have to worry about keeping BC.
We just create a new interface instead. When people actually need these
things in scripts (and I don't see them needing it) then we can add it, and
create an Ex version or a V2 version or even a whole new interface for this
stuff.
Adding support for scripts needlessly complicates our API because we're trying
to anticipate a use that doesn't exist yet.
--
Matt
More information about the KDevelop-devel
mailing list