Re: [Paraview] patch for 9485 Save camera position
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.lor...@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.lor...@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 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] patch for 9485 Save camera position
Hi Utkarsh,
I hadn't heard back from you in a couple weeks I saw you asking about
usability improvements, I think saving camera configuration as in the
patch I sent in with this thread is a good one :)I'm hoping not to let
this slip through the cracks. What can I do to make this happen
(assuming you still like the idea) ?
Thanks
Burlen
burlen wrote:
Hi Utkarsh,
finally I have a chance to take a look at this in depth and get back
to you.
What can't configuration merely be a subset of
the state i.e. same as the state xml for that proxy except with only
the required properties?
The difference between state and configuration goes beyond the latter
being a simple subset of the proxy's properties.
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.
Another distinction is that the state of domains aren't needed by
configuration.
The main advantage will be that we don't have
another serialization format to handle.
Yes, that's a fair point. We could pretty easily make use of the
lowest level of the state implementation,
vtkSMXXVectorProperty::SaveChildState and
vtkSMXXVectorProperty::LoadState, if they were public methods. Why
aren't these public methods? Will it be OK to make them public? And
what about the name SaveChildSate, why not just SaveState?
I didn't go down this road in large part because I know how important
state is to PV, know changing the implementation is sensitive and
involved task, and didn't want to tackle it without your input. But
there were also a couple other motivations for a new format and
implementation.
In regard to the current state implementation and file format, the
file format is fairly inefficient for example each value in a property
vector is written to disk as a nested xml element (ie a vector with
256 values, requires 257 xml elements). Also in terms of the
implementation it's very fragile , you modify a state file by hand and
make a mistake and it crashes PV during the load. I've also seen PV
crash loading state across major PV versions. All of these facts
dampened my enthusiasm for making use of the current state
implementation and motivated to me to provide the new format and fault
tolerant implementation.
I implemented validate methods
(vtkSMXXVectorProperty::ValidateConfiguration) that will parse the XML
and validate it without making any changes to the property. This is
key to a fault tolerant implementation, the manager can then validate
the configuration before applying it. I specifically wanted to prevent
a partial load that will leave the property in an indeterminate state.
I think these features are important, nothing is more frustrating
than going to load a state file and having PV crash. If we make use of
the current state vtkSMXXVectorProperty::SaveChildState and
vtkSMXXVectorProperty::LoadState for reading and writing the
configuration XML we'll still want the validate function don't you think?
Plus, you can directly use
the state loading infrastructure to load the configuration without
having to write the configuration loader classes.
My implementation in its current form one does indeed have to
implement two classes, one reader and one writer. But this involves a
minimal effort of implementing the following methods from
vtkSMProxyConfigurationReader/Writer to return various cstrings.
virtual const char *GetFileExtension()=0;
virtual const char *GetFileIdentifier()=0;
virtual const char *GetFileDescription()=0;
virtual const char *GetReader/WriterVersion(){ return 1.0; }
I think it makes sense to require an implementor to provide this meta
data. These are mostly used for high level file validation and to
make the file dialog work and error reporting meaningful, but also
make the file format more human friendly. Beyond implementing these
three methods no coding is needed, because one can can provide a list
of property names to operate on at any time using the
vtkSMPropertyConfigurationManager base class interface.
In the case of the camera configuration, it made sense to have a
specialized reader implementation vtkSMCameraConfigurationReader that
could also handle updating the view after a configuration was loaded
and it was convenient to provide the list of property names in the
constructor. Providing this list in the constructor is the simplest
way for specialized implementations. That doesn't neccessarilly
preclude a more general use case. For example for something more
general like a reader writer pair for PV's geometric sources, only the
three pure virtual mothods mentioned above would be implemented, and
we would provide property names on the fly as the panels are decorated.
The current implementation makes it possible for custom panel
implementors to simply
Re: [Paraview] patch for 9485 Save camera position
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 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] patch for 9485 Save camera position
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 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] patch for 9485 Save camera position
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.lor...@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 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] patch for 9485 Save camera position
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.lor...@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 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] patch for 9485 Save camera position
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.lor...@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.lor...@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 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] patch for 9485 Save camera position
Hi Utkarsh,
finally I have a chance to take a look at this in depth and get back to you.
What can't configuration merely be a subset of
the state i.e. same as the state xml for that proxy except with only
the required properties?
The difference between state and configuration goes beyond the latter
being a simple subset of the proxy's properties.
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.
Another distinction is that the state of domains aren't needed by
configuration.
The main advantage will be that we don't have
another serialization format to handle.
Yes, that's a fair point. We could pretty easily make use of the lowest
level of the state implementation, vtkSMXXVectorProperty::SaveChildState
and vtkSMXXVectorProperty::LoadState, if they were public methods. Why
aren't these public methods? Will it be OK to make them public? And what
about the name SaveChildSate, why not just SaveState?
I didn't go down this road in large part because I know how important
state is to PV, know changing the implementation is sensitive and
involved task, and didn't want to tackle it without your input. But
there were also a couple other motivations for a new format and
implementation.
In regard to the current state implementation and file format, the file
format is fairly inefficient for example each value in a property vector
is written to disk as a nested xml element (ie a vector with 256 values,
requires 257 xml elements). Also in terms of the implementation it's
very fragile , you modify a state file by hand and make a mistake and it
crashes PV during the load. I've also seen PV crash loading state across
major PV versions. All of these facts dampened my enthusiasm for making
use of the current state implementation and motivated to me to provide
the new format and fault tolerant implementation.
I implemented validate methods
(vtkSMXXVectorProperty::ValidateConfiguration) that will parse the XML
and validate it without making any changes to the property. This is key
to a fault tolerant implementation, the manager can then validate the
configuration before applying it. I specifically wanted to prevent a
partial load that will leave the property in an indeterminate state.
I think these features are important, nothing is more frustrating than
going to load a state file and having PV crash. If we make use of the
current state vtkSMXXVectorProperty::SaveChildState and
vtkSMXXVectorProperty::LoadState for reading and writing the
configuration XML we'll still want the validate function don't you think?
Plus, you can directly use
the state loading infrastructure to load the configuration without
having to write the configuration loader classes.
My implementation in its current form one does indeed have to implement
two classes, one reader and one writer. But this involves a minimal
effort of implementing the following methods from
vtkSMProxyConfigurationReader/Writer to return various cstrings.
virtual const char *GetFileExtension()=0;
virtual const char *GetFileIdentifier()=0;
virtual const char *GetFileDescription()=0;
virtual const char *GetReader/WriterVersion(){ return 1.0; }
I think it makes sense to require an implementor to provide this meta
data. These are mostly used for high level file validation and to make
the file dialog work and error reporting meaningful, but also make the
file format more human friendly. Beyond implementing these three methods
no coding is needed, because one can can provide a list of property
names to operate on at any time using the
vtkSMPropertyConfigurationManager base class interface.
In the case of the camera configuration, it made sense to have a
specialized reader implementation vtkSMCameraConfigurationReader that
could also handle updating the view after a configuration was loaded and
it was convenient to provide the list of property names in the
constructor. Providing this list in the constructor is the simplest way
for specialized implementations. That doesn't neccessarilly preclude a
more general use case. For example for something more general like a
reader writer pair for PV's geometric sources, only the three pure
virtual mothods mentioned above would be implemented, and we would
provide property names on the fly as the panels are decorated.
The current implementation makes it possible for custom panel
implementors to simply implement their own configuration reader writer
pair as needed. I think that's an important feature of any solution that
we come up with.
Not to get too far ahead of myself, here, just want to explain some of
my thinking in more depth than I did originally.
Also, one of the reasons for the existence
vtkSMProxyConfigurationManager seems to be the fact that
Re: [Paraview] patch for 9485 Save camera position
Burlen, That's really cool. I like the the notion of configuration, but I have a few questions. What can't configuration merely be a subset of the state i.e. same as the state xml for that proxy except with only the required properties? The main advantage will be that we don't have another serialization format to handle. Plus, you can directly use the state loading infrastructure to load the configuration without having to write the configuration loader classes. Also, one of the reasons for the existence vtkSMProxyConfigurationManager seems to be the fact that state loading results in creating of new proxies, but then, that's not necessarily true. State can be loaded on existing proxies as well -- we do that for undo-redo. The trick is provide the right vtkSMProxyLocator (or a subclass) (if I remember correctly). What do you think? Utkarsh On Mon, Jan 25, 2010 at 2:40 AM, burlen burlen.lor...@gmail.com wrote: Sorry to resend this, but the attachments were too big for the list. I put them here: http://nashi-submaster.ucsd.edu/movies/PV/save-cam-config/ Hi all, The attached patch is for fetaure 9485 Save camera position( http://public.kitware.com/Bug/view.php?id=9485 ) . This solution provides a way of converting the camera configuration into an XML stream which can then be either: stored in PV's internal settings to be later accessed by one of 4 camera dialog buttons; or written to a file to be later read back in. I attached screen shots of the modified camera dialog and custom view button configuration dialog so you can take a quick look and see what this is all about. Is this something I can commit as is? If not what needs to change? A little about the implementation follows and I'd like to propose adding a related feature, the ability to individually save and load configuration of PV's geomtry sources (point, line, plane, sphere etc...). Saving and loading the camera configuration is a special case of a more general missing feature, that of saving and loading a subset of an individual proxy's properties. I am calling this configuration. Something like state but much simpler, lighter and more portable. With that in mind, rather than make a one off camera configuration reader/writer, I took a more general approach in my solution and implemented camera configuration reader/writer pair from abstract proxy configuration reader/writer base classes. A simple way to use these proxy configuration classes is to implement a derived class, and in the constructor initialize the list of properties that will comprise the configuration. The base classes can then handle the validation and IO of the XML hierarchy. Using these classes one could also do something similar to save and load any subset of any proxy's vector properties pretty easily. My intentions is that configuration can step in for state in the cases where state is overkill, or doesn't work. For instance when trying to reproduce a figure on a different cluster the most crucial aspects are often the positioning of geometric sources and the camera. these are also often the most difficult to recreate by hand since they require precise positioning. unlike state, configuration is not tied to a specific cluster or connection. It also provides a quick way to duplicate a source in the same session. A configuration file depends only on a single proxy minimizing the risk of backward incompatibility over time. the gist of the approach I have in mind to expose this functionality for PV's geometry sources would be by way of a qt widget containing a load and a save button placed in the object inspector auto generated panels. The widget would only be added if the SM XML requested it. The XML would be something like this: SourceProxy ... ... ConfigurationManagerProperty PropertyDomain name=managed_properties values=... /ConfigurationManagerProperty ... /SourceProxy The XML would be added to each of the geometry sources. The properties that make up the configuration of an individual source would be explicitly listed in the managed_properties attribute and passed into the geometry source configuration reader/writer objects which would be derived from vtkSMProxyConfigurationReader/Writer in the attached patch. Is this going to be a committable feature? Comments and feedback are much appreciated. I know its a really small feature, but I think it will improve the user's experience, and resolve some frustrations with state. Thanks Burlen Scott, W Alan wrote: I just wrote this one up as bug number 9805. We really should have this functionality in ParaView. Thanks for catching this one. Alan -Original Message- From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org] On Behalf Of Utkarsh Ayachit Sent: Friday, October 30, 2009 4:25 AM To: Bam Ting Cc: bastil2...@yahoo.de; ParaView Subject: Re: [Paraview] Save camera setting paraview 3.6.1 I agree. We lost
Re: [Paraview] patch for 9485 Save camera position
Yes, you are right, it will be better to use existing sate writing mechanism if at all possible. I did attempt it, but hit some obstacles. At the time I was unaware about the undo-redo uses state this way, so let me take a look at that. I'll get back to you soon. Utkarsh Ayachit wrote: Burlen, That's really cool. I like the the notion of configuration, but I have a few questions. What can't configuration merely be a subset of the state i.e. same as the state xml for that proxy except with only the required properties? The main advantage will be that we don't have another serialization format to handle. Plus, you can directly use the state loading infrastructure to load the configuration without having to write the configuration loader classes. Also, one of the reasons for the existence vtkSMProxyConfigurationManager seems to be the fact that state loading results in creating of new proxies, but then, that's not necessarily true. State can be loaded on existing proxies as well -- we do that for undo-redo. The trick is provide the right vtkSMProxyLocator (or a subclass) (if I remember correctly). What do you think? Utkarsh On Mon, Jan 25, 2010 at 2:40 AM, burlen burlen.lor...@gmail.com wrote: Sorry to resend this, but the attachments were too big for the list. I put them here: http://nashi-submaster.ucsd.edu/movies/PV/save-cam-config/ Hi all, The attached patch is for fetaure 9485 Save camera position( http://public.kitware.com/Bug/view.php?id=9485 ) . This solution provides a way of converting the camera configuration into an XML stream which can then be either: stored in PV's internal settings to be later accessed by one of 4 camera dialog buttons; or written to a file to be later read back in. I attached screen shots of the modified camera dialog and custom view button configuration dialog so you can take a quick look and see what this is all about. Is this something I can commit as is? If not what needs to change? A little about the implementation follows and I'd like to propose adding a related feature, the ability to individually save and load configuration of PV's geomtry sources (point, line, plane, sphere etc...). Saving and loading the camera configuration is a special case of a more general missing feature, that of saving and loading a subset of an individual proxy's properties. I am calling this configuration. Something like state but much simpler, lighter and more portable. With that in mind, rather than make a one off camera configuration reader/writer, I took a more general approach in my solution and implemented camera configuration reader/writer pair from abstract proxy configuration reader/writer base classes. A simple way to use these proxy configuration classes is to implement a derived class, and in the constructor initialize the list of properties that will comprise the configuration. The base classes can then handle the validation and IO of the XML hierarchy. Using these classes one could also do something similar to save and load any subset of any proxy's vector properties pretty easily. My intentions is that configuration can step in for state in the cases where state is overkill, or doesn't work. For instance when trying to reproduce a figure on a different cluster the most crucial aspects are often the positioning of geometric sources and the camera. these are also often the most difficult to recreate by hand since they require precise positioning. unlike state, configuration is not tied to a specific cluster or connection. It also provides a quick way to duplicate a source in the same session. A configuration file depends only on a single proxy minimizing the risk of backward incompatibility over time. the gist of the approach I have in mind to expose this functionality for PV's geometry sources would be by way of a qt widget containing a load and a save button placed in the object inspector auto generated panels. The widget would only be added if the SM XML requested it. The XML would be something like this: SourceProxy ... ... ConfigurationManagerProperty PropertyDomain name=managed_properties values=... /ConfigurationManagerProperty ... /SourceProxy The XML would be added to each of the geometry sources. The properties that make up the configuration of an individual source would be explicitly listed in the managed_properties attribute and passed into the geometry source configuration reader/writer objects which would be derived from vtkSMProxyConfigurationReader/Writer in the attached patch. Is this going to be a committable feature? Comments and feedback are much appreciated. I know its a really small feature, but I think it will improve the user's experience, and resolve some frustrations with state. Thanks Burlen Scott, W Alan wrote: I just wrote this one up as bug number 9805. We really should have this functionality in ParaView. Thanks for catching this one. Alan -Original Message- From: paraview-boun...@paraview.org
