adding and removing items from a buildtool

[Andreas Pakulat]

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.

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

> - Why do we ask for an Url? wouldn't it be better to provide a string
> relative to the parent? (which could be a url, though...)

Why not :) Passing in a KUrl makes sure we don't do unecessary url-parsing,
because everything else will also use a url. Passing around relative paths
for files is one of the things that created the worst headaches I've ever
had with KDevelop3.

> - Return types: my idea is not to actually put the new items but to open the
> editor with the things changed so that the user only have to save the file
> (that way the user can review what has changed and check if he is happy with
> the change or undo it if he didn't like it). That means that the new item is
> not yet created when returning on that method.

Letting the user review the changes is good, however I guess you're going
to re-parse the file afterwards, which means you won't emit the signals for
addition/removal so other plugins relying on those signals won't get them.

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.

> Who should actually add/remove the directories/files/whatever?

What do you mean with "who" here? Who's using the API? Well the
projectmanagerview for example.

Andreas 

-- 
You will soon meet a person who will play an important role in your life.