KDevelop4 API questions

Adam Treat treat at kde.org
Thu Aug 17 01:14:55 UTC 2006


On Wednesday 16 August 2006 8:14 pm, Matt Rogers wrote:
> 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.

Please don't.  I know I need to document them, but they do have a purpose...

projectDirectory == the dir where the current project file is located.

projectsDirectory == the dir where the user holds all of his project 
folders ... perhaps this can be renamed to better illustrate what it is.

Both of them are useful though, please don't remove.

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

All it has is the extension.  We can easily make an API for setting this 
extension.

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

Why would this be made virtual?  How many ways are you going to open a project 
file?

Adam




More information about the KDevelop-devel mailing list