iproject API

[Aleix]

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, but for sure we could leverage the
context menu extension (i don't think it is the proper place to
configure the vcs).

>
>
>  > - 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).

>
>  Andreas
>
>
>  --
>  You never know how many friends you have until you rent a house on the beach.
>
>
>  _______________________________________________
>  KDevelop-devel mailing list
>  KDevelop-devel at kdevelop.org
>  https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>