adding and removing items from a buildtool

[Andreas Pakulat]

On 12.11.08 11:49:32, Aleix wrote:
> On Wed, Nov 12, 2008 at 5:55 AM, Andreas Pakulat <apaku at gmx.de> wrote:
> 
> > On 12.11.08 02:57:12, Aleix wrote:
> > > hi!
> > > I was taking a look at the API we have right now to add and remove items
> > > from a buildtool (IProjectFileManager + IBuildSystemManager), here there
> > are
> > > some thoughts:
> > > - We can either add files to a target or to a folder, sounds confusing
> > (even
> > > if i understand the reason).
> >
> > Not really, IMHO. Adding a file to a folder means putting that file
> > somewhere into the project tree, whatever type of file. Adding a file to a
> > target means: "I want this target to use the code from this file".
> >
> > >    -> Why don't he overload to add to a folder or a target depending on
> > the
> > > parent type?
> >
> > You mean renaming the addFileToTarget function in the buildsystemmanager?
> > I'm split here between consistent API (i.e. renaming it) and clear API that
> > tells you what it'll do. I guess with good code-completion its easy enough
> > to see that the parameters have different types. I don't want to see the
> > the method being called with a ProjectBaseItem because thats not verbose
> > enough on which types are allowed and which are not.
> 
> Well, we only can add it to a Directory and to a Target, 2 cases, not 1
> baseitem.

Yeah, as I said I'm undecided of having the same method name with different
parameters, i.e. having

addFile( const KUrl& file, ProjectFolderItem* item);

in IProjectFileManager and 

addFile( ProjectFileItem*, ProjectTargetItem* );

in IBuildSystemManager. I simply don't know if this might be confusing or
not.
 
> > > - If we can rename a file we should provide it its new parent, not just
> > the
> > > Url, same for directory.
> >
> > Why? If you not just rename, but also move the file, you can find the right
> > parent folder easily by using the new-url. You can't move around a file
> > from one target to another this way, in fact I think existing targets using
> > the old file need to automatically be changed to use the new filename.
> >
> Then why do we need the parent when adding a file? We could just figure out
> too.

Indeed. With our current project tree there's no reason why you'd have a
folder with items in it that point into another folder. Except maybe, if
those files are outside the projects source dir. Hmm, so we could probably
have the ProjectFolderItem default to 0 and inside the addFile
implementation use it only if its != 0 and the file is inside the projects
sourcedir.

> > So, I'm not sure we should let the user edit the file when add/remove was
> > called in the API. A simple preview-widget that shows the area thats going
> > to be changed could be enough, if the user wants to do something more
> > complex, he can just cancel this and write the CMakeLists.txt file
> > manually.
> 
> That's the other option I had in mind... Do you think it is better?

Yes I think so. If we allow the user to edit the CMake-file for adding a
.cpp to the project, he can also do other things we don't know about. Which
means we'd have to reparse the file, which means we can't possibly know
wether the file was added or not, so we can't emit the signal. 

Andreas 

-- 
Learn to pause -- or nothing worthwhile can catch up to you.