[prev in list] [next in list] [prev in thread] [next in thread]
List: kdevelop-devel
Subject: Re: adding and removing items from a buildtool
From: Aleix <aleixpol () gmail ! com>
Date: 2008-11-12 12:19:50
Message-ID: 757d9a550811120419w475e01e4i8f9c10a2d91754 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Nov 12, 2008 at 1:01 PM, Andreas Pakulat <apaku@gmx.de> wrote:
> On 12.11.08 11:49:32, Aleix wrote:
> > On Wed, Nov 12, 2008 at 5:55 AM, Andreas Pakulat <apaku@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?
>
>
> > > > - 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 or
maybe we just want to track the model changes...
>
> Andreas
>
> --
> Learn to pause -- or nothing worthwhile can catch up to you.
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel@kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
[Attachment #5 (text/html)]
<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>
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic