Re: [JPP-Devel] Feature collections modified by default

[Stefan S. <ss...@ge...>]

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
> Jum...@li...
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel