<br><br><div class="gmail_quote">On Wed, Nov 12, 2008 at 5:55 AM, Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 12.11.08 02:57:12, Aleix wrote:<br>
> hi!<br>
> I was taking a look at the API we have right now to add and remove items<br>
> from a buildtool (IProjectFileManager + IBuildSystemManager), here there are<br>
> some thoughts:<br>
> - We can either add files to a target or to a folder, sounds confusing (even<br>
> if i understand the reason).<br>
<br>
</div>Not really, IMHO. Adding a file to a folder means putting that file<br>
somewhere into the project tree, whatever type of file. Adding a file to a<br>
target means: "I want this target to use the code from this file".<br>
<div class="Ih2E3d"><br>
>    -> Why don't he overload to add to a folder or a target depending on the<br>
> parent type?<br>
<br>
</div>You mean renaming the addFileToTarget function in the buildsystemmanager?<br>
I'm split here between consistent API (i.e. renaming it) and clear API that<br>
tells you what it'll do. I guess with good code-completion its easy enough<br>
to see that the parameters have different types. I don't want to see the<br>
the method being called with a ProjectBaseItem because thats not verbose<br>
enough on which types are allowed and which are not.</blockquote><div>Well, we only can add it to a Directory and to a Target, 2 cases, not 1 baseitem.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="Ih2E3d"><br>
> - If we can rename a file we should provide it its new parent, not just the<br>
> Url, same for directory.<br>
<br>
</div>Why? If you not just rename, but also move the file, you can find the right<br>
parent folder easily by using the new-url. You can't move around a file<br>
from one target to another this way, in fact I think existing targets using<br>
the old file need to automatically be changed to use the new filename.<br>
<div class="Ih2E3d"></div></blockquote><div>Then why do we need the parent when adding a file? We could just figure out too.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
> - Why do we ask for an Url? wouldn't it be better to provide a string<br>
> relative to the parent? (which could be a url, though...)<br>
<br>
</div>Why not :) Passing in a KUrl makes sure we don't do unecessary url-parsing,<br>
because everything else will also use a url. Passing around relative paths<br>
for files is one of the things that created the worst headaches I've ever<br>
had with KDevelop3.</blockquote><div>Ok. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
> - Return types: my idea is not to actually put the new items but to open the<br>
> editor with the things changed so that the user only have to save the file<br>
> (that way the user can review what has changed and check if he is happy with<br>
> the change or undo it if he didn't like it). That means that the new item is<br>
> not yet created when returning on that method.<br>
<br>
</div>Letting the user review the changes is good, however I guess you're going<br>
to re-parse the file afterwards, which means you won't emit the signals for<br>
addition/removal so other plugins relying on those signals won't get them.</blockquote><div>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;<br>
<br>if(!manager->addFile(bla))<br>      MessageBox::error("Big error");<br>) <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
So, I'm not sure we should let the user edit the file when add/remove was<br>
called in the API. A simple preview-widget that shows the area thats going<br>
to be changed could be enough, if the user wants to do something more<br>
complex, he can just cancel this and write the CMakeLists.txt file<br>
manually.</blockquote><div>That's the other option I had in mind... Do you think it is better?<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="Ih2E3d"><br>
> Who should actually add/remove the directories/files/whatever?<br>
<br>
</div>What do you mean with "who" here? Who's using the API? Well the<br>
projectmanagerview for example.</blockquote><div>Ok <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Andreas<br>
<font color="#888888"><br>
--<br>
You will soon meet a person who will play an important role in your life.<br>
<br>
_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</font></blockquote></div><br>