Re: [JPP-Devel] Feature collections modified by default
Michaël Michaud wrote: Hi, I can commit your patch next week, if you did not do it before. ok, I've committed the patch, including the T\: language strings as suggested. Thanks, 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.dehttp://www.deegree.org Follow deegree on Twitter: http://twitter.com/deegree_org signature.asc Description: Digital signature -- 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
Re: [JPP-Devel] Feature collections modified by default
Thanks Andreas Andreas Schmitz wrote: Michaël Michaud wrote: Hi, I can commit your patch next week, if you did not do it before. ok, I've committed the patch, including the T\: language strings as suggested. 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
Re: [JPP-Devel] Feature collections modified by default
Hi Andreas, Thanks a lot. Your patch seems to work like a charm. Michaël Andreas Schmitz a écrit : Michaël Michaud wrote: Hi, I can commit your patch next week, if you did not do it before. ok, I've committed the patch, including the T\: language strings as suggested. 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
Re: [JPP-Devel] Feature collections modified by default
Andreas Schmitz a écrit : key ;-) By the way, do I need to insert the keys into all the language files, or are the ones I know a translation for sufficient? To facilitate translation work, we usually put the key with the english default in all language files, preceded by T\: for those needing a translation. ex. newkey = T\:english message needing translation * new feature collections are again unmodified by default * PlugInContext is unmodified * when OpenJUMP is closed, and there are layers with null data sources, the user is asked whether he still wants to exit the workbench Seems OK to me Do we then still need the confirmation dialog when nothing is modified and no datasources are null? For now I've removed it again (personally I don't like to be asked too many questions that could have been avoided), but it would be easy enough to add it back. I agree with that I can commit your patch next week, if you did not do it before. Thanks for the work Best regards, Michaël -- 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
Re: [JPP-Devel] Feature collections modified by default
Michaël Michaud wrote:
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.
yes, I agree, I also think that a sensible default is better that such a
confusion.
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)
Yeah, I'm trying to get the message right and end up with a typo in the
key ;-)
By the way, do I need to insert the keys into all the language files, or
are the ones I know a translation for sufficient?
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.
I think it's a great idea to just check for null datasources, and warn
the user if there are such layers. It's the cleanest solution to the
problem.
I've attached a patch with the following:
* new feature collections are again unmodified by default
* PlugInContext is unmodified
* when OpenJUMP is closed, and there are layers with null data sources,
the user is asked whether he still wants to exit the workbench
Do we then still need the confirmation dialog when nothing is modified
and no datasources are null? For now I've removed it again (personally I
don't like to be asked too many questions that could have been avoided),
but it would be easy enough to add it back.
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.dehttp://www.deegree.org
Follow deegree on Twitter: http://twitter.com/deegree_org
Index: src/language/jump.properties
===
--- src/language/jump.properties(revision 2002)
+++ src/language/jump.properties(working copy)
@@ -1701,6 +1701,8 @@
ui.WorkbenchFrame.committed-memory = Committed Memory
ui.WorkbenchFrame.continue = Continue
ui.WorkbenchFrame.dataset = Dataset
+ui.WorkbenchFrame.do-you-really-want-to-close-openjump-generated-layers-not-saved
= Do you really want to close OpenJUMP?\n\
+{0} automatically generated layers have not been saved yet.
ui.WorkbenchFrame.do-you-want-to-close-them-also = Do you want to close them
also ?
ui.WorkbenchFrame.exit = Exit
ui.WorkbenchFrame.exit-jump = Exit OpenJUMP
Index: src/language/jump_en.properties
===
--- src/language/jump_en.properties (revision 2002)
+++ src/language/jump_en.properties (working copy)
@@ -1663,6 +1663,8 @@
ui.WorkbenchFrame.committed-memory = Committed Memory
ui.WorkbenchFrame.continue = Continue
ui.WorkbenchFrame.dataset = Dataset
+ui.WorkbenchFrame.do-you-really-want-to-close-openjump-generated-layers-not-saved
= Do you really want to close OpenJUMP?\n\
+{0} automatically generated layers have not been saved yet.
ui.WorkbenchFrame.do-you-want-to-close-them-also = Do you want to close them
also ?
ui.WorkbenchFrame.exit = Exit
ui.WorkbenchFrame.exit-jump = Exit OpenJUMP
Index: src/language/jump_de.properties
===
--- src/language/jump_de.properties (revision 2002)
+++ src/language/jump_de.properties (working copy)
@@ -1664,6 +1664,8 @@
ui.WorkbenchFrame.committed-memory = Verwendeter Speicher
ui.WorkbenchFrame.continue = Weiter
ui.WorkbenchFrame.dataset = Datensatz
+ui.WorkbenchFrame.do-you-really-want-to-close-openjump-generated-layers-not-saved
= Wollen Sie OpenJUMP wirklich beenden?\n\
+{0} automatisch erzeugte Ebenen wurden noch nicht gespeichert.
Re: [JPP-Devel] Feature collections modified by default
Stefan Steiniger wrote:
Hi,
finally I'm getting back to this.
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.
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, 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.dehttp://www.deegree.org
Follow deegree on Twitter: http://twitter.com/deegree_org
Index: src/language/jump.properties
===
--- src/language/jump.properties(revision 1994)
+++ src/language/jump.properties(working copy)
@@ -1701,6 +1701,7 @@
ui.WorkbenchFrame.committed-memory = Committed Memory
ui.WorkbenchFrame.continue = Continue
ui.WorkbenchFrame.dataset = Dataset
+ui.WorkbenchFramw.do-you-really-want-to-close-openjump = Do you really want to
close OpenJUMP?
ui.WorkbenchFrame.do-you-want-to-close-them-also = Do you want to close them
also ?
ui.WorkbenchFrame.exit = Exit
ui.WorkbenchFrame.exit-jump = Exit OpenJUMP
Index: src/language/jump_en.properties
===
--- src/language/jump_en.properties (revision 1994)
+++ src/language/jump_en.properties (working copy)
@@ -1663,6 +1663,7 @@
ui.WorkbenchFrame.committed-memory = Committed Memory
ui.WorkbenchFrame.continue = Continue
ui.WorkbenchFrame.dataset = Dataset
+ui.WorkbenchFramw.do-you-really-want-to-close-openjump = Do you really want to
close OpenJUMP?
ui.WorkbenchFrame.do-you-want-to-close-them-also = Do you want to close them
also ?
ui.WorkbenchFrame.exit = Exit
ui.WorkbenchFrame.exit-jump = Exit OpenJUMP
Index: src/language/jump_de.properties
===
--- src/language/jump_de.properties (revision 1994)
+++ src/language/jump_de.properties (working copy)
@@ -1664,6 +1664,7 @@
ui.WorkbenchFrame.committed-memory = Verwendeter Speicher
ui.WorkbenchFrame.continue = Weiter
ui.WorkbenchFrame.dataset = Datensatz
+ui.WorkbenchFramw.do-you-really-want-to-close-openjump = Wollen Sie OpenJUMP
wirklich beenden?
ui.WorkbenchFrame.do-you-want-to-close-them-also = Wollen Sie diese ebenfalls
schliessen?
ui.WorkbenchFrame.exit = OpenJUMP beenden
ui.WorkbenchFrame.exit-jump = JUMP Beenden
Index: src/com/vividsolutions/jump/workbench/plugin/PlugInContext.java
===
--- src/com/vividsolutions/jump/workbench/plugin/PlugInContext.java
(revision 1994)
+++ src/com/vividsolutions/jump/workbench/plugin/PlugInContext.java
(working copy)
@@ -155,6 +155,16 @@
return getLayerManager().addLayer(categoryName, layerName,
featureCollection);
}
+public Layer addLayer(
+String categoryName,
+String layerName,
+FeatureCollection featureCollection,
+boolean featureCollectionModified) {
+Layer l = getLayerManager().addLayer(categoryName, layerName,
featureCollection);
+l.setFeatureCollectionModified(featureCollectionModified);
+return l;
+}
+
public void addLayerSextanteRaster(
String categoryName,
RasterImageLayer raster) {
Index: src/com/vividsolutions/jump/workbench/model/Layer.java
===
--- src/com/vividsolutions/jump/workbench/model/Layer.java (revision 1994)
+++ src/com/vividsolutions/jump/workbench/model/Layer.java (working copy)
@@ -115,9 +115,6 @@
getBasicStyle().setLineColor(defaultLineColor(fillColor));
getBasicStyle().setAlpha(150);
setFeatureCollection(featureCollection);
- // michaelm [2009-02-20] consider that a new layer is modified
- // so that a confirmation is asked before application closing
- featureCollectionModified = true;
}
/**
Index: src/com/vividsolutions/jump/workbench/ui/WorkbenchFrame.java
===
--- src/com/vividsolutions/jump/workbench/ui/WorkbenchFrame.java
(revision 1994)
+++ src/com/vividsolutions/jump/workbench/ui/WorkbenchFrame.java
(working copy)
@@ -1270,9
Re: [JPP-Devel] Feature collections modified by default
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
Re: [JPP-Devel] Feature collections modified by default
Hei Michael, 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... mhm.. interesting did not think about this either. Right now everything done in Sextante, which produces a new raster layer, will create a new (tif) file (in the windows temp folder) and then loads this file. So basically these files continue exists - but the user doesn't know about it. There is also no properties dialog as for the vector layers. So the user doesn't know if the image/raster is saved somewhere or not. Well, I guess adding here a dialog may not be the hardest task if time is given ;) stefan Michaël -- 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
Re: [JPP-Devel] Feature collections modified by default
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 -- 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.dehttp://www.deegree.org Follow deegree on Twitter: http://twitter.com/deegree_org signature.asc Description: Digital 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 Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Feature collections modified by default
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. Larry On Fri, Jul 9, 2010 at 3:11 AM, Andreas Schmitz schm...@lat-lon.de 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 -- 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.dehttp://www.deegree.org Follow deegree on Twitter: http://twitter.com/deegree_org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkw22ZcACgkQ737OVr+Ru7pZdwCg7JXRzrulKfyOgjrCQ4VGf/IA /Y0An0V8zjml7vetBTr1l2HambBLCmJV =3hbj -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 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
Re: [JPP-Devel] Feature collections modified by default
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
Re: [JPP-Devel] Feature collections modified by default
Hi Andreas 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've already changed this experimentally (locally), and if everyone agrees, I'd like to commit it when it's done. for my poiny of view yours is an useful modification. I vote to commit it Peppe -- 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
Re: [JPP-Devel] Feature collections modified by default
Andreas, Your comments make sense to me, but lets wait a couple more days for Michael to comment before we commit a patch. Thanks, The Sunburned Surveyor On Thu, Jul 8, 2010 at 3:57 AM, Giuseppe Aruta giuseppe_ar...@yahoo.it wrote: Hi Andreas 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've already changed this experimentally (locally), and if everyone agrees, I'd like to commit it when it's done. for my poiny of view yours is an useful modification. I vote to commit it Peppe -- 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
Re: [JPP-Devel] Feature collections modified by default
Hi Andreas, 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 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 regards, Michaël What do you 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
