new KDevPlatform API for consideration

[Matt Rogers]

On Tuesday 23 May 2006 02:25, Jens Herden wrote:
> Hi,
>
> > Thanks for any comments and feedback.
>
> I looked briefly into it.
>
> In KDevFileManager is an enum Feature where the Files entry should get a
> 0x0004 to make it or-able, at least that is how I understand QFlag().
> Should we reserve some values in that enum for future use? I saw that some
> enum definitions in QT define a user-value entry two mark the reserved
> space.
>
> In kdevbuildmanager.h: Do you need to assign values in the BuildFeature
> enum to make them or-able.
>

That's the whole point of QFlags as I understand them, so we don't have to 
define values for the enum in order to use them as flags. I'll look into 
this, thanks for pointing it out.

> I wonder if some methods of KDevProject should better move into
> KDevFileManager? I mean: inProject, absoluteUrl, relativeUrl. For me this
> seems more natural to combine them there.

inProject is a convenience method. absoluteUrl and relativeUrl refer to the 
project file as I understand it (and can remember w/o looking at the code)

> But I also read this here:
>  * KDevProject is a container for everything which relates to the files
>  * within a development project.  It maintains a list of files contained
>  * in it.
>

the docs are a bit outdated as we didn't care too much about keeping them up 
to date when moving things around.

> So maybe the best solution would be to drop KDevFileManager and put the
> stuff directly into KDevProject? I mean can we imagine projects without
> files? And even if there are some, they can carry the overhead.
> What you would need than is a setBuildManager for projects which actually
> support building.
>

no, the whole point of KDevFileManager is to move all of that stuff out of 
KDevProject.  We just need to update the KDevProject docs. :)

> In KDevProject: setFileManager takes no ownership of the the given object,
> right? It would suggest to comment this just to make it clear.
>
> In general I am happy to see this new code and the switch to KUrl.
>
> I'd like to know if one implementation of a KDevFileManager would be part
> of the platform?
>

I don't know about that yet. There is currently a generic importer in 
kdevelop/buildtools/importers/generic which after porting could go into the 
platform, but that will have to wait until later.

> If yes, I am thinking about a way to associate custom data to a
> KDevProjectItem. I mean like KFileItem is doing it. If we would have this
> Quanta and others could use the default project of KDevelop and just add
> pointers to specific data to the items. This would be very flexible and
> could be used from different plugins at the same time.
>
> Forgive me if my very limited knowledge about KDevelop made me write
> nonsense in this mail.
>
> Jens

No nonsense here. Just a few things that need to be cleaned up. :)

--
Matt