KDevelop4 API questions

Andras Mantia amantia at kde.org
Wed Aug 16 11:12:44 UTC 2006


 We've been starting/continuing to work on integrating Quanta with 
KDevelop4 and while we've been looking to the new API some questions 
have been arisen. I would like to ask for comments and help for anybody 
knowing this classes.

1. KDevProjectController
There are methods called projectsDirectory/setProjectsDirectory and 
projectDirectory. This is dangerous, as one might easily make a mistake 
by putting or not putting that "s" there. Aside of that it is not clear 
the meaning and the difference of the above two. What are the 
"projects" method for? The assumption is that the project file can be 
at a different place than the project content and the "projects" method 
are for the content itself. Is this true? BTW, we didn't really saw an 
example of their usage, only something in the konsole plugin which is 
also a strange code.
If anyway there is a need for both, we suggest to rename the 
projectDirectory to "globalFileDirectory" as actually it refers to the 
place where the globalFile (project file) is. Or something like that.

KDevProjectController::openProject: the open dialog has hardcoded 
information about KDevelop4 project files. This one should be 
configurable in some way. Ideas are welcome.

2. KDevProject

This one also has a projectDirectory() thing. What is the difference 
between this and the above? Does it point to the same 
"globalFileDirectory" or should point to the directory where the 
project content is? In any case, why is it here as well and in the 
controller? I'd suggest to keep it only here.

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.

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.

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 
to a 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? Or one could just create 
a new KDevProjectFileItem pointing to the same URL and pass this to 
removeFile? 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.
So can we agree on one behavior and document it? Unfortunately none of 
the currently written importers have this methods implemented.

4. KDevProjectFileItem

This is a dark area for us. We will study it a little bit more, but 
right now it is unclear of the relation between all those KDev*Item 
classes and the inheritance diagram (like why the FileItem is derived 
from a collection, the difference between collection and group, etc.). 
If anyone has a clear overview about this and could share with us, we 
would be happy. :-)


That is for now, hopefully you could help us. 


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/20060816/87407bd9/attachment.sig>

More information about the KDevelop-devel mailing list