I'm not sure it helps, and I haven't tried it on WFS layers, but
theoretically my "select all modified features" plugin distinguishes between
newly created features and features loaded from a dataset.
On Fri, Jul 9, 2010 at 3:11 AM, Andreas Schmitz <schmitz@...> wrote:
> Michaël Michaud wrote:
> > > I've noticed that (for quite some time now) newly loaded feature
> > > collections/layers are now considered modified by default. I've been
> > > using that check in the WFS plugin to enable the update button only if
> > > the layer is actually modified. I've added a workaround to set the
> > > unmodified immediately after loading.
> > >
> > Sorry for the inconvenience
> that's no problem. I've shot myself in the foot like that often enough
> > > I've also found the place where layers are set to modified after
> > > (in the Layer class, with a comment from Michaël, that's why I'm
> > > addressing you directly ;-)). I'm not entirely sure why it is done like
> > > this. Was your intention to have a 'do you really want to close OJ'
> > > message when closing? If so, I'd like to propose to have a check when
> > > closing, and show a different message if no layers have been modified,
> > > asking just that, and only show the modified warning if something has
> > > actually been modified. I find it confusing for the users to have a
> > > warning like this, when he did actually not modify anything...
> > >
> > You probably are right, as it may be important to make the difference
> > between a newly created layer and a modified layer.
> > I'll try to make my problem clearer as I'm not sure to get the solution
> > Some layers are issued from a persistent datasource, and others have
> > been created by the application (ex. a buffer layer).
> > How to inform the user who closes the application that some newly
> > created layers are unsaved to disk (some of my co-workers complained
> > they lost their work without any warning)
> > Maybe I missed something simple with the Layer.getDataSourceQuery method.
> > I'll try to explore this method (probably after my vacations).
> > Feel free to get back to the previous state of Layer class if needed.
> > I'm quite confident another way can be found to solve my problem
> ah, now I understand the problem. I think in the case of generated
> layers it makes perfect sense to have them marked modified at creation
> time. I suppose the best solution would then be to proceed as I
> suggested (it's still nice to get a confirmation message when exiting
> even though nothing is modified I think), and manually set generated
> layers to be modified when creating them. I see two options here:
> * by default set new layers to be unmodified, set generated layers to
> be modified when creating them (this must then be done in all plugins
> that generate new layers)
> * by default set new layers to be modified, set layers that are loaded
> from file/database/WFS etc. to be unmodified (this must then be done
> in all plugins which do not generate features)
> If we decide on one direction, I can make the changes to the code if
> someone can provide me with a list of (core) plugins that need to be
> I'm not sure about the other solution that seems slumbering in your mind
> (you certainly know the code better than me). Also no need to rush (you
> can enjoy your vacation first!).
> What do people think?
> Best regards, Andreas
> l a t / l o n GmbH
> Aennchenstrasse 19 53177 Bonn, Germany
> phone ++49 +228 18496-0 fax ++49 +228 1849629
> http://www.lat-lon.de http://www.deegree.org
> Follow deegree on Twitter: http://twitter.com/deegree_org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> -----END PGP SIGNATURE-----
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> Jump-pilot-devel mailing list