<br><br><div class="gmail_quote">On Wed, Nov 12, 2008 at 1:01 PM, 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><div></div><div class="Wj3C7c">On 12.11.08 11:49:32, Aleix wrote:<br>
> On Wed, Nov 12, 2008 at 5:55 AM, Andreas Pakulat <<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>> wrote:<br>
><br>
> > 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<br>
> > are<br>
> > > some thoughts:<br>
> > > - We can either add files to a target or to a folder, sounds confusing<br>
> > (even<br>
> > > if i understand the reason).<br>
> ><br>
> > 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>
> ><br>
> > >    -> Why don't he overload to add to a folder or a target depending on<br>
> > the<br>
> > > parent type?<br>
> ><br>
> > 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.<br>
><br>
> Well, we only can add it to a Directory and to a Target, 2 cases, not 1<br>
> baseitem.<br>
<br>
</div></div>Yeah, as I said I'm undecided of having the same method name with different<br>
parameters, i.e. having<br>
<br>
addFile( const KUrl& file, ProjectFolderItem* item);<br>
<br>
in IProjectFileManager and<br>
<br>
addFile( ProjectFileItem*, ProjectTargetItem* );<br>
<br>
in IBuildSystemManager. I simply don't know if this might be confusing or<br>
not.</blockquote><div>Project items are created by the projectmanager now, do you want to change that?<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<br>
> > the<br>
> > > Url, same for directory.<br>
> ><br>
> > 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>
> ><br>
> Then why do we need the parent when adding a file? We could just figure out<br>
> too.<br>
<br>
</div>Indeed. With our current project tree there's no reason why you'd have a<br>
folder with items in it that point into another folder. Except maybe, if<br>
those files are outside the projects source dir. Hmm, so we could probably<br>
have the ProjectFolderItem default to 0 and inside the addFile<br>
implementation use it only if its != 0 and the file is inside the projects<br>
sourcedir.<br>
<div class="Ih2E3d"><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.<br>
><br>
> That's the other option I had in mind... Do you think it is better?<br>
<br>
</div>Yes I think so. If we allow the user to edit the CMake-file for adding a<br>
.cpp to the project, he can also do other things we don't know about. Which<br>
means we'd have to reparse the file, which means we can't possibly know<br>
wether the file was added or not, so we can't emit the signal.</blockquote><div>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 or maybe we just want to track the model changes...<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>
Andreas<br>
<font color="#888888"><br>
--<br>
Learn to pause -- or nothing worthwhile can catch up to you.<br>
</font><div><div></div><div class="Wj3C7c"><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>
</div></div></blockquote></div><br>