[Paraview] patch for 9485 Save camera position

[burlen]

Hi Utkarsh,

I made the changes as we discussed. The patch is blocked by the mail 
list. I put it here:
  http://nashi-submaster.ucsd.edu/movies/PV/save-cam-config/saveCam2.patch

I ran it through valgrind and ctest and it's clean. Let me know how to 
proceed.

Thanks
Burlen


Utkarsh Ayachit wrote:
> 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
>>>>>
>>>>>
>>>>>           
>>>>         
>>