new KDevPlatform API for consideration

[Hamish Rodda]

On Thursday 25 May 2006 21:30, Jens Herden wrote:
> > > > no, the whole point of KDevFileManager is to move all of that stuff
> > > > out of KDevProject.  We just need to update the KDevProject docs. :)
> > >
> > > Can you explain why you want to do this?
> >
> > Because KDevFileManager (and derivatives) is the interface to the project
> > manager part and the file handling stuff that was already in KDevProject
> > would duplicate what's in KDevFileManager. KDevFileManager is a
> > combination of the current KDevProjectImporter and KDevProjectEditor
> > classes in trunk.
>
> Why not the other way around. What will be left in KDevProject after moving
> all file related methods into KDevFileManager? I still think it is more
> natural to have the methods from KDevFileManager in KDevProject and drop
> KDevFileManager. Maybe there are reason that I can not see why this is not
> good?

This is all about abstracting build systems, which are provided by plugins. 
KDevFileManager is the class which will be inherited by those plugins.

KDevProject is a place for common functionality.  I hope that such things like 
running an application would not have to require a separate implementation 
for each build system this way.

This separation also means that (even though it's a quite a corner case) we 
can interchange build systems on the fly, and maybe even one day support 
maintaining multiple build systems for one project - an example of this would 
be roberto's parser, or threadweaver, using cmake + qmake.

> > > > > 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.
> > >
> > > You said nothing about this idea?
> > >
> > > Jens
> >
> > I didn't have anything to say about it, so I stayed silent rather than
> > just say something completely non-sensical. :) I don't know how KFileItem
> > associates custom data. I know that to add custom data, you would need a
> > KDevProjectItem derivative, and perhaps your own file manager. what type
> > of custom data are you talking about?  Do you have use cases about how it
> > would be used? Right now, I think it's overkill, since I don't see it
> > being used much, but I'm willing to be educated. :)
>
> So now I know what to do :-)
> First why I think this would be a good idea. We have information about the
> upload status that is connected to a file in the project. It would be nice
> to be able to connect them to a project item instead of creating a map
> between KURL and the data.
>
> KFileItem has an internal map from pointer to pointer. So code that wants
> to associate data can just put the class pointer with a pointer to the data
> structure into this. Later the class can retrieve the data pointer very
> easy. The beauty of this solution is that every plugin can associate its
> own data and looking up the data is rather quick.
>
> So the idea is to avoid KDevProjectItem derivatives because this would mean
> you need to know in advance what data you want to add to it. This loose
> coupling I suggest is more flexible and does not need to derive at all.

Yes, and it has to be this way, because the build system by rights is the one 
which can create derivatives to store data.

The only issue is if more than one plugin wants to do this, so we may have to 
have a list of plugin, variant pairs to store this data, but that's ok.

I also disagree with using KShared for these objects (and other model 
objects), they have a well defined time when they should be created and 
deleted.  Probably they should be QObjects so we can emit interesting signals 
etc.

So this area can certainly use more work...

Cheers,
Hamish.
-------------- 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/20060525/e9b984ea/attachment.sig>