KDevelop4 API questions

[Andras Mantia]

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.

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

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20060817/ff63b048/attachment.sig>