adding and removing items from a buildtool

[Aleix]

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.


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


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

Ok.

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

Then I'd return false values that could mean that there is no way to
determine if it was a proper change (lets say this wouldn't work;

if(!manager->addFile(bla))
      MessageBox::error("Big error");
)

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


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

Ok

>
> Andreas
>
> --
> You will soon meet a person who will play an important role in your life.
>
> _______________________________________________
> 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/20081112/232b44f8/attachment.html>