Hei Andreas and Michael, playing save is what we should do. For creating new layers I am most often using context.addLayer() - so why not adding the flagging there instead of changing all plugins? An option would be to create a second addLayer() method with a boolean parameter for flagging if the new layer is "modified".
However, this wouldn't work for context.getLayerManager().addLayerable(..) - which is used for (Sextante) Rasters. I.e. needs changes there too. my thoughts stefan Andreas Schmitz wrote: > Michaël Michaud wrote: > > Hi, > >>> 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 layer >>> 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 loading >>> (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 yet. >> >> 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 > modified. > > 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 > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel ------------------------------------------------------------------------------ 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 Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
