[Paraview] patch for 9485 Save camera position

[burlen]

> since that will
> allow you to clean domains from the DOM as well.
OK. But when you said:

> Honestly domains should not be saved in the normal state as well,
> since we never load them back.
They never get loaded back, so their presence won't have a negative 
effect. Besides, if they're not used then there's no reason to have them 
in the state machinery at all. If that's the case we shouldn't let them 
influence the design of a new feature. Perhaps domains should just be 
eliminated from state.

Although practically speaking generating the full dom and cleaning won't 
have a noticeable impact on performance for configuration since they are 
small sets of properties, it just it feels iky. But if that's what you 
want I'm game :)

Burlen


Utkarsh Ayachit wrote:
> Burlen,
>
> Further thinking about this, I think filtering the DOM before saving
> out the configuration (rather than changing SaveState() signature to
> take optional list of properties) maybe even better, since that will
> allow you to clean domains from the DOM as well.
>
> Utkarsh
>
> On Fri, Feb 26, 2010 at 4:15 PM, burlen <burlen.loring at gmail.com> wrote:
>   
>> Hi Utkarsh,
>>
>> Just to summarize our off list conversation in case any one else is
>> following this thread:
>>
>> We'll not use my new serialization code but rather the current public
>> methods  vtkSMProxy::LoadSate/SaveState . We'll add an additional optional
>> argument to the method signatures so that the properties to be saved or
>> loaded can be filtered (eg filter camera related properties in
>> vtkSMRenderViewProxy when saving camera configuration).
>>
>> I'll send the fix as soon as I can.
>>
>> Thanks again
>> Burlen
>>
>> Utkarsh Ayachit wrote:
>>     
>>> Hi Burlen,
>>>
>>> The functionality is indeed great. The only hesitation I have is with
>>> burdening server manager code with another serialization code. My
>>> comments are inlined.
>>>
>>>
>>>       
>>>>> One substantial difference is that connection id is central in the state
>>>>> implementation. however not only is it not needed for configuration but
>>>>> it
>>>>> cannot be used with configuration. So for configuration the lack of a
>>>>> connection id is a central feature.
>>>>>
>>>>>           
>>> Not necessarily true. If you look at vtkSMProxy. It has a method
>>> LoadState() which simply takes in the XMLElement to simply load the
>>> given state on the proxy. If you look at  vtkSMDeserializer (the base
>>> class for state loaders), by providing a right locator to locate the
>>> proxy that the state XML is asking for, the connection id doesn't even
>>> come in the picture. Further more, you can easily provide a totally
>>> separate state loader class for the configuration without having to
>>> add any thing to the properties, proxies
>>>
>>>
>>>       
>>>>> Another distinction is that the state of domains aren't needed by
>>>>> configuration.
>>>>>
>>>>>           
>>> Honestly domains should not be saved in the normal state as well,
>>> since we never load them back.
>>>
>>> But I agree with you that your configuration files are much easier to
>>> edit and read. An alternative solution would be keep that code
>>> isolated i.e. we don't really need to add the Save/Load methods to
>>> vtkSMProxy, vtkSMProperty etc. for the configuration, you can always
>>> simply get/set the property values in your serializer/loader classes.
>>> What do you think?
>>>
>>> Utkarsh
>>>
>>>       
>>