iproject API

[Andreas Pakulat]

On 28.07.08 22:11:15, Aleix wrote:
> On 7/28/08, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 27.07.08 23:25:24, Aleix wrote:
> >  > Hi,
> >  > I was looking at the KDevelop::IProject class and I find some things strange:
> >  >
> >  > - virtual IPlugin* versionControlPlugin() const:
> >  > Is it being used at all? If we have this, why do we have all this mess
> >  > of items when right-clicking on an item in the project model view?
> >
> >
> > Access to the VC plugin of a project is needed, even if not used right
> >  now. Think about plugins doing refactoring/file-renaming, those need to
> >  check for VC plugin.
> Then we should restrict a project to a VC plugin or use this call to
> call all of them at the same time

Neither. The "Version Control" entry will work on the projects "primary"
VCS, which still needs a kcm to change it. However its nice to be able
to use a different VCS sometimes for the same project locally (I've once
needed to import a CVS-managed project into an SVN tree and it was quite
nice to being able to run cvs update in it to keep in sync with
"upstream"), so the entries "Subversion","Git",... will stay.

>, but for sure we could leverage the context menu extension (i don't
>think it is the proper place to configure the vcs).

I'm not sure what you mean with this. Currently there's simply no place
to configure the vcs for a project.

> >  > - Aren't redundant these methods?
> >  >     virtual int fileCount() const = 0;
> >  >     virtual ProjectFileItem* fileAt( int ) const = 0;
> >  >     virtual QList<ProjectFileItem*> files() const = 0;
> >  > And if not, is it that useful?
> >
> >
> > There once was a page on our wiki talking about the first two methods
> >  being "the right API" and the latter being not so good. I can't find it
> >  right now and I've already forgot the reasoning.
> >
> >  According to a quick grep the QList<> version is used quite a bit. I'm
> >  not sure what to do, can somebody else shed some light on why the first
> >  two methods are better API than the latter?
> If a plugin wants to iterate through all files, looks like it might be
> faster to put all pointers to a list and then to return the list than
> to have the indices. First of all indices are not persistant (so we
> can't be sure that the index n will always point to the same file) and
> in a list we can iterate using iterators and such. Maybe a QSet would
> be more accuarte though (not sure).

A QSet would be better I think, as it doesn't leave the impression that
the returned set of items is in any defined order - which it isn't.

Andreas

-- 
Don't look now, but there is a multi-legged creature on your shoulder.