KDevelop4 API questions

[Matt Rogers]

On Wednesday 16 August 2006 06:12, Andras Mantia wrote:
> 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.
>

are they actually used anywhere? If not, then we can remove them and if we 
need them later, then add them then.


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

If the file dialog is created here, shouldn't this be made virtual so that 
others can provide their own impl?


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

This is definately the project directory for the currently open project. 

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

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

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

> Or one could just create 
> a new KDevProjectFileItem pointing to the same URL and pass this to
> removeFile? 

It's not supposed to work this way, ideally. As mentioned above, the only use 
case for this so far is if removal is done via the GUI. However, if you have 
other use cases, we can make changes to accomdate.

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

> So can we agree on one behavior and document it? Unfortunately none of
> the currently written importers have this methods implemented.
>

Indeed.

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

Welcome to KDevelop's probably overengineered model/view stuff. :) That's all 
the *Item classes are for. However, somebody removed the actual use of the Qt 
model view stuff from those classes for reasons I still don't understand. /me 
glances at manyoso.

>
> That is for now, hopefully you could help us.
>

Hopefully this helps
--
Matt