[Paraview-developers] More server manager woes.

[Moreland, Kenneth]

Since nobody seems to be using it anyway, I went ahead and got rid of
the ModifiedAtCreation flag and replaced it with a
MarkAllPropertiesAsModified method in vtkSMProxy.

I think we are in agreement that proxies should have commands in
addition to properties, but that is too big of a change that I want to
take on.  Instead, I added a feature request  to the ParaView bug
tracker (#1783).

-Ken

   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********  
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      fax:   (505) 845-0833


> -----Original Message-----
> From: Berk Geveci [mailto:berk.geveci at gmail.com] 
> Sent: Wednesday, April 20, 2005 11:21 AM
> To: Moreland, Kenneth
> Cc: paraview-developers at paraview.org
> Subject: Re: [Paraview-developers] More server manager woes.
> 
> > (1) Should the ModifiedAtCreation flag really exist?  The 
> point seems 
> > to be to make sure that when the object is created, its 
> state reflects 
> > the default values specified in the xml.  Is that important?  Why 
> > would the default values in the xml be more important than those in 
> > the class itself?  Does it matter that they don't agree?  These are 
> > proxy objects after all.  The programmer must know of the 
> possibility 
> > that the state does not match up perfectly.  ParaView turns 
> this flag 
> > off.  Is there any client that really needs it on?  Could it be 
> > replaced with a method in vtkProxy that updates all 
> properties regardless of the modified flag?
> 
> I think that a method that pushed all values whether they are 
> modified or not is better than using ModifiedAtCreation.  I 
> can't remember the motivation behind the flag but I have no 
> objection to removing it. The web stuff might depend on it 
> though. Utkarsh? Andy?
> 
> > (2) Should everything in a proxy be a property?  A property, in my 
> > mind, is just a piece of state.  Both "Render" and 
> "ForceUpdate" are 
> > not really properties in that sense.  They are commands that invoke 
> > some sort of process.  They may change the state, but 
> probably in ways 
> > far outside those of other properties.  To me (and probably to most
> > programmers) setting a property named "ForceUpdate" seems 
> far removed 
> > from "update the upstream pipeline now."  Is this hokey mechanism 
> > better than just using a client/server stream directly?  Should 
> > proxies also have commands in addition to properties?  That 
> would help 
> > prevent code from blindly doing pipeline updates or renders when it 
> > thinks it's just modifying some fields in a class.
> 
> I agree with these too. I actually prefer a C++ interface for 
> things like render, update etc. However, for applications 
> that require a property like interface a command object makes 
> more sense. However this is a bit tricky because properties 
> do not have access to the actual ids so they can't directly 
> invoke. Here is one way of doing it:
> * Make command subclass of property, make sure 
> ImmediateUpdate is on and that Modified is false.
> * Add Invoke command that calls this->Modified()
> 
>