KDevelop4 API questions

[Matt Rogers]

On Thursday 17 August 2006 01:36, Andras Mantia wrote:
> On Thursday 17 August 2006 03:14, Matt Rogers wrote:
> Hi and thanks for the answers!
>
> > > inProject method in KDevProject: the implementation is completely
> > > wrong and we have no idea why it is implemented here at all.
> > > KDevProject has pure virtual methods, so this should be pure
> > > virtual as well and the implementation removed from the lib.
> >
> > KDevProject should not be completely pure virtual. inProject is
> > supposed to query the file manager and determine if the file is part
> > of the project that way.
>
> It already has pure virtual methods, so the class is pure virtual. :-) I
> don't mind having the inProject implemented there, but than it should
> be implemented for real. ;-)
>
> > > absoluteUrl: in the implementation there is a call to KUrl with the
> > > KUrl(KUrl, QString) constructor to combine an absolute url with a
> > > relative path. The problem is that the docs for KUrl clearly say
> > > that one should not use a *path* for the second argument, but an
> > > encoded string. And here a path is used, so this looks wrong to me
> > > and possibly will fail in some cases.
> >
> > absoluteUrl probably needs to go away. The file managers should
> > already be using absolute URLs, so I'm not sure where this would be
> > needed at all.
>
> Right now it is only used in the bogus inProject implementation...
>
> > > 3. KDevFileManager
> > >
> > > As we understood in order to open a project, add/remove files to
> > > the project there is a need to implement a KDevFileManager class.
> > > What we like to know is how did you imagine handling of files that
> > > were added toza project. The addFile returns a pointer to a
> > > KDevProjectFileItem. When a file is removed/renamed do you expect
> > > that this very same pointer is passed to remove/renameFile method?
> >
> > Yes, that same pointer would need to be passed to
> > removeFile/renameFile. However, I would imagine that this would
> > automatically taken care of by the GUI when it's fleshed out a bit
> > more.  I would imagine that we don't need those functions to return a
> > KDevProjectFileItem anymore, since they should be added to their
> > respective folder/target/whatever it was added to.
>
> so you mean that they should take a KUrl and all the other thing is done
> inside the filemanager? I support this idea.
>

Yes, that's what I mean. :)

> > > I understand that this is up to our FileManager class, but
> > > I think there is a need to have a standard behavior, otherwise 3rd
> > > party plugins wanting to access and modify the project structure
> > > could be coded based on different assumptions.
> >
> > It's not really up to the file manager implementation, but rather the
> > project manager implementation really. At least that's how it should
> > work when it comes to calling addFile, removeFile, renameFile, etc.
>
> Well yes, they work together, but both can be called independently from
> 3rd party plugins.
>

Indeed. Let's see how it evolves.
--
Matt