Hi, > ok. I've attached patch which changes the following: > > * new feature collections are again unmodified by default > * PlugInContext has an added addLayer method taking a > featureCollectionModified parameter for convenience > * when OpenJUMP is closed, and no layers have been modified, it still > asks whether you want to really exit the workbench > > What are the opinions on this? > Thanks to have worked on this problem. If I understand correctly, proposed change are :
1 - OpenJUMP will always asks for confirmation before closing. 2 - OpenJUMP will still inform the user that some layers have been modified if these layers have really been modified (not just created) 3 - Programmer can now create new layers as unmodified or as modified layers (see below my remark) 4 - Existing plugin produce unmodified layers. There is point 3 that I dislike for the following reason : If we have not a clear policy about what is a modified layer, we'll soon have half newly created layers considered as modified and half considered as unmodified, thus confusing the user and introducing inconsistencies. To solve my initial problem, I think I can rely on the getDataSourceQuery which returns null for layers which are not yet saved to disk. My proposition is to let you change everything you put in the patch except the new method in PluginContext (there is also a typo in the key added in language files and in confirmClose method) I can see if a test on every Layer.getDataSourceQuery in the WorkbenchFrame.confirmClose method can solve my initial problem, by informing the user there is still one, or to, or n layers without datasource. What do you think ? Side note : in both cases, the solution is added at the Layer level and does not take raster into account. I wonder if modification status and dataSource should be shared by all AbstractLayerable ? But this is another question... Michaël > Thanks, Andreas > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel