Re: KDE/kdevelop/lib/plugins/vcs/interfaces

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

-- 
You are standing on my toes.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel