Extending the IProjectFileManager interface

[Matt Rogers]

On Jul 3, 2007, at 1:10 PM, Andras Mantia wrote:

> Hi,
>
>  we are discussing here with Jens the need of storing certain
> information for each file inside the project. One case in Quanta would
> be storing information about uploads (to the web server): when the  
> file
> was last uploaded, should it be uploaded or not at all, should it be
> uploaded without asking the user for confirmation.
> I can imagine that other plugins would also like to store information
> about a file belonging to the project.
>  Our idea was to store such information in the project configuration
> file (the "local" one if such exists now, not the one that is shared
> between users).
>  I'm writing this mail to ask feedback about how do you think we  
> should
> go on. The solution are:
> 1) Extend IProjectFileManager with the needed methods (probably
> something like writeProperty(ProjectItem*, key, value) and
> readProperty(ProjectItem*, key) ). The IProjectFileManager would
> contain a default implementation for these methods, so there is no  
> need
> to reimplement them in every project file manager, unless there is a
> need for a different behavior. Our way of implementing this would be
> storing every file as a group (in the KConfig object) and add the
> key/value pairs to it.
>
> 2) Write our own little plugin which does the above and put it in  
> either
> Quanta (so only Quanta plugins would benefit of this), or in
> kdevplatform.
>
> Andras
>
> --

3. Create ProjectItem subclasses to store the data for the item with  
that item. They should be able to save their data to the file of  
their choice as requested by taking a QDataStream. Something like:

QuantaFileItem::save( const QDataStream& );

for a declaration.

#3 is the idea I like the best. It seems the cleanest from my point  
of view and doesn't require changing our API.
--
Matt