new KDevPlatform API for consideration

[Jens Herden]

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


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

Jens


-------------- 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/5b4e66a1/attachment.sig>