projectmanager interface

[Andreas Pakulat]

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

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.

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