projectmanager interface

[Aleix Pol]

On Sat, Dec 27, 2008 at 12:18 PM, Andreas Pakulat <apaku at gmx.de> wrote:

> On 26.12.08 20:36:29, Aleix Pol wrote:
> > On Fri, Dec 26, 2008 at 5:19 AM, Matt Rogers <mattr at kde.org> wrote:
> > > On Wednesday 24 December 2008 07:35:17 pm Aleix Pol wrote:
> > > > hi,
> > > > I've been checking the project modification interface and there are
> some
> > > > things that look a bit strange.
> > > >
> > > > - why do we need the removeFileFromTarget when we have a removeFile?
> we
> > > can
> > > > check if it is from an item using
> > > > dynamic_cast<ProjectTargetItem*>(it->parent()).
> > >
> > > What happens if you want to remove a file from a target and move it to
> > > another
> > > target? That was the use-case that removeFileFromTarget was intended
> for.
> > > If
> > > removeFile is a destructive action (i.e. the file gets deleted) then
> this
> > > is
> > > still needed. It also makes the operation explicit in terms of API.
> >
> > Maybe the name is wrong?
> > By now the file is deleted by the projectmanagerview though, not by the
> > plugin. the plugin just makes sure that the change is coherent with the
> > call.
>
> I'm not sure the project-manager-plugin (i.e. cmake/qmake/etc) should be
> doing the deletion because:
>
> a) it duplicates code
> b) thats not the task of those plugins, they should just manage the
> buildsystem/project-file-list
>
Well, I think it is quite clear that the buildtool should not delete the
files by themselves. it should be done by the vcs plugin, instead.


> However, that still leaves the case Matt explained: I want to remove file
> foo.cpp from target a, which should leave that file in the project, but
> simply not attach it to a certain target.

Then we should remove it from the buildtool but not from the filesystem
(which is not performed by this interface) and then add the file again to
another parent :/.


>
>
> > > > - why do we have addFileToTarget and addFile(toFolder)? and the
> target
> > > case
> > > > has a ProjectFileItem as a parameter instead of a KUrl :S
> > >
> > > because the addFile call is expected to take place before the
> > > addFileToTarget
> > > call. You can have files in the project file structure and not have
> them be
> > > part of the target (think README, TODO, and HACKING files)
> >
> > These files won't be added to a target but to a folder.
> >
> > It doesn't really make sense to me to have to add the file first to a
> parent
> > and then reparent it to another one.
>
> But it makes the API more consistent, because for every addXXX there's a
> removeXXX and vice-versa. Having such API is good, because people don't
> need to lookup the methods as its obviously clear what methods exist.
>
> > > > - why don't we just merge these methods that just pass the same and
> we
> > > pass
> > > > a ProjectBaseItem as the parent?
> > >
> > > I also don't understand this question. Could you be more explicit?
> >
> > why don't we have addItem(ProjectBaseItem*) instead of every addFile,
> > Folder, Target.
>
> Because its more explicit in the API. That way if you use this API you
> instantly see what is added at a certain point. Sometimes more verbose code
> is good.
>
> Especially with the two interfaces IPFM and IBSM we'd have a differing
> behaviour of the same method, depending on wether the underlying plugin is
> a buildsystem or just project manager. This might be totally invisible from
> the place of the call of the addItem.
>
> Andreas
>
> --
> Try the Moo Shu Pork.  It is especially good today.
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20081227/b80b73ef/attachment.html>