[Paraview] patch for 9485 Save camera position

[Utkarsh Ayachit]

Either way :). I don;t think I have a preference, just wanted to put
it out there.

Utkarsh

On Fri, Feb 26, 2010 at 7:55 PM, burlen <burlen.loring at gmail.com> wrote:
>
>> 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
>>>>
>>>>
>>>
>>>
>
>