[Paraview] patch for 9485 Save camera position

[Utkarsh Ayachit]

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
>>
>
>