KDevelop4 API questions
Andras Mantia
amantia at kde.org
Wed Aug 16 11:12:44 UTC 2006
Hi,
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. :-)
5.
That is for now, hopefully you could help us.
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/20060816/87407bd9/attachment.sig>
More information about the KDevelop-devel
mailing list