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