KDevelop4 API questions

[Matt Rogers]

On Thursday 17 August 2006 02:29, Jens Herden wrote:
> > > > 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.
> >
> > But not all project folders are in the same place, so I still don't see
> > the point of either of these functions since projectDirectory is
> > duplicated from KDevProject and well, right now, projectsDirectory
> > doesn't make sense to me.
>
> Oh that is new for me. I thought that project files and folders must have a
> common base folder? But the project file can be at an arbitrary location
> where also the hidden .kde4 folder is created. Am I wrong here?
>

Yes, project files and folders must reside under a particular folder. However, 
the project file can no longer be stored at an arbitrary location. We might 
change that, dunno yet, a lot of this stuff is still in flux.

> > > > > 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
> >
> > I dunno. That's why I asked the question. :) If it doesn't need to be
> > virtual and we can provide API that says "use this extension (or even
> > better, mimetype) when looking for project files to open" then that's
> > fine too --
>
> Or simply read it from the configuration file with a default for the
> current value. We could just provide a different value in Quanta's
> configuration file then. I think an API would be too much.
>
> Jens
>

If you store the value in quanta's config file, you still need a way to say, 
"this is the mimetype for my project files", so you still need the API for 
this.
--
Matt