adding and removing items from a buildtool

[Andreas Pakulat]

On 12.11.08 13:19:50, Aleix wrote:
> On Wed, Nov 12, 2008 at 1:01 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> 
> > 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.
> 
> Project items are created by the projectmanager now, do you want to change
> that?

No, of course not. The above implies that one first has to add a file to
the project by using addFile( KUrl, ProjectFolderItem) and only then can do
a addFile( ProjectFileItem, ProjectTargetItem).

Hmm, so actually we might want to return a ProjectFileItem from
addFile(KUrl, ProjectFolderItem). Else one would have to search through the
project to find the file item.
 
> > > > > - 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.
> 
> Maybe we have to track states when reloading because if the user wants to
> change it manually we will want to get these signals then... isn't it? :S

IMHO thats far too complex, if the user edits the CMakeLists.txt manually
we just reload the necessary parts of the project model. Maybe we could add
a convenience signal "reloaded( ProjectBaseItem newitem, ProjectBaseItem
olditem)" when doing this, but the information is also available by using
the rowsInserted/rowsRemoved signals from the model

> or maybe we just want to track the model changes...

Trying to emit fileadded/removed via tracking model changes is also quite
complex.

Andreas

-- 
You are the only person to ever get this message.