Yes .. I got carried away and put up a patch implementing the projectWrite 
signal in the QgisInterface before I saw this alternative.  Though in fact I do 
think that is makes sense to have a QgsInterface projectSaved() signal matching 
the projectRead().  And maybe a savingProject() that happens before it is saved.

I forgot about needing to catch changes in the memory provider data to set the 
dirty state .. This was part of my original plan for implementing the memory 
provider data into the project file itself but I forgot it in my excitement 
about a plug in option.  (The excitement is about being to do it now - I still 
think this really belongs in the core system). 

Maybe if I can trap an event relating to saving edits, then if the edited layer 
provider is a memory provider I can set the project state to dirty.  And 
plugins will have to set the dirty state themselves (this may happen anyway, eg 
when the contour plugin generates a new contour layer adding the layer sets the 
state).  This is getting a bit messy though!

So maybe there is still some work required to provide the signals for changes 
to vector provider data.  In fact the project does need to take ownership of 
the data.  For it all to make sense it needs a projectDataDirty() flag.  Bother!

Chris

-----Original Message-----
From: b.rowling...@googlemail.com [mailto:b.rowling...@googlemail.com] On 
Behalf Of Barry Rowlingson
Sent: Tuesday, 7 December 2010 12:21 p.m.
To: Chris Crook
Cc: Martin Dobias; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Memory data provider persistence

On Mon, Dec 6, 2010 at 7:12 PM, Chris Crook <ccr...@linz.govt.nz> wrote:
> Hi Barry et al
>
> Good point about a plugin implementation .. I hadn't thought of that obvious 
> option - definitely one to follow up on.  It might still need a few tweaks in 
> terms of Qgis.  The QgisInterface has a projectRead() signal that could be 
> used to trigger reloading the data, but I don't see a projectSaved() signal 
> to trigger writing.  Easy to add that though, and probably generally useful.

 There's a projectWrite signal:

http://www.qgis.org/api/classQgsProject.html#a935c811d84c51e908c73868be9b69c4

 which seems to be emitted before the layers are saved, so if anything hooked 
into that wants to make changes it should be able to. Haven't tried, but will 
that do the job?

> Given that there is a signal to hook in to this is, as you say, a piece of 
> cake.  I'm kicking myself for not having thought of this months ago!!

 The only problem might be if the memory provider doesn't set the project as 
dirty when it changes itself. Otherwise users could do a 'quit', and then qgis 
quits without chance to save the project.

> In terms of file location my preference would be something directly related 
> to the project file .. That is obviously easy.  And shapefile is not my 
> choice, just because of the messy bunch of files it creates and having so 
> many of them and because the DBF format is limiting and pretty scungy!  But 
> that is personal preference I guess.

 Agreed! I've been saving things as GML lately.

Barry
______________________________________________________________________________________________________

This message contains information, which is confidential and may be subject to 
legal privilege. 
If you are not the intended recipient, you must not peruse, use, disseminate, 
distribute or copy this message.
If you have received this message in error, please notify us immediately (Phone 
0800 665 463 or i...@linz.govt.nz) and destroy the original message.
LINZ accepts no responsibility for changes to this email, or for any 
attachments, after its transmission from LINZ.

Thank you.
______________________________________________________________________________________________________
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Reply via email to