[Paraview] ParaViews vtkCommonPython is not the sam as in VTK

[Utkarsh Ayachit]

Hi Milan,

The "Glyph" properties are an anomaly to the general rule. I'd rather 
they were renamed to "ScaleMode" "Orient" from "SetScaleMode", 
"SetOrient". This may be done in future, and the change  will be 
backwards compatible (as far as possible).

The fix you suggested seems fine for "Set" but for "Get", it tries to 
search for a property with the name "GetScaleMode", which does not 
exists. In keep with the general norm where we prepend the property name 
with Get or Set, one can do the following:

filter.SetSetScaleMode(...) or
filter.GetSetScaleMode(...).

The pyProxy API is very new. I can see improvements to it as users start 
using it and raise issues/suggestions. As with most of paraview, we'll 
try to keep the changes backwards compatible as far as possible.

Utkarsh.


Milan Frank wrote:
> Hi Utkarsh,
> 
> thank you for your suggestions and nice wiki page. Great job! It
> helped me a lot.
> 
> I'm trying to use your "paraview" python module. It works fine.
> However, I was in need to modify it a bit. Your convenient access
> methods do not work with properties beginning with "get/set" prefix.
> (ie.: "Glyph" has a property named "SetScaleMode"). I have added these
> few lines to the pyProxy.__getattr__ method:
> 
>        if re.compile("^Set").match(name) and 
> self.SMProxy.GetProperty(name):
>            self.__LastAttrName = name
>            return self.__SetProperty__
>        if re.compile("^Get").match(name) and 
> self.SMProxy.GetProperty(name):
>            self.__LastAttrName = name
>            return self.__GetProperty__
> 
> It seems, it solves the problem. I'm not sure if it is not causing
> some other (for me hidden) problems. What do you think?
> 
> I'd like to ask you another question. Can I consider the interface of
> the pyProxy class as more less stable or do you plan any major
> changes? I'd like to start using it ASAP.
> 
> Thanks,
> Milan.
> 
> 
> On 8/4/06, Utkarsh Ayachit <utkarsh.ayachit at kitware.com> wrote:
>> Hi Milan,
>>
>> ParaView does not warp all of VTK simply to keep the size of the python
>> libraries down. Also, the utility of wrapping all VTK is minimal. Since
>> in the ParaView environment, one cannot use VTK objects directly, one
>> should use proxies etc etc. Ofcourse, a small subset it still necessary
>> and that's what vtkCommonPython is in ParaView.
>>
>> I think I know why you are getting the Invalid Connection ID error.
>> Previously pvpython was exactly like pvbatch (except with a python
>> interpreter instead of tcl). In batch mode, there is not concept of
>> server connections. When the client would start up, it would create an
>> internal "server" which was used for all the VTK objects created etc etc.
>>
>> Since we wanted to make the python client a full-fledged client, it was
>> essential that it supported connecting to remote servers. Hence, now the
>> pvpython is more like pvclient. You have to connect to a server
>> explicitly. Ofcourse, one can simply connect to a "built-in" server on
>> the client itself, it doesn't have to be remote. But, one has to create
>> that connection. We've introduced a new "paraview" module that
>> simplifies the creation of connections etc etc. Here's a link to the
>> Wiki page:
>>
>> http://www.paraview.org/Wiki/index.php?title=ParaView:pvpython
>>
>> The points to remember are that every script must create a connection
>> and then on every proxy created, we must set the correct connection ID.
>>
>> Utkarsh.
>>
>>
>> Milan Frank wrote:
>> > Hi Utkarsh,
>> >
>> > honestly, my biggest problem is the size and complexity of the
>> > ParaViews CMake scripts. They are also modified very often by other
>> > developers. To maintain my separate branch consists of time consuming
>> > and error-susceptible merging. That is why I have used my
>> > minimalistic, unclear solution (to employ VTKs vtkXxxPython.dll
>> > instead of the ParaViews vtkCommonPython.dll).
>> >
>> > What I have done ... First of all, I built VTK separately (directly
>> > from the ParaView source code tree). Than I manually copied created
>> > python wrappers (vtkXxxPython.lib and vtkXxxPython.dll) into paraviews
>> > "bin" build directory.
>> >
>> > After that, I simply commented out the "KIT Common" part (Line: 153 to
>> > EOF) in the ParaView\Utilities\VTKPythonWrapping\CMakeLists.txt file.
>> > I suppose, this is responsible for the creation of the
>> > vtkCommonPython.lib/.dll. So, the manually copied one is not
>> > rewritten.
>> >
>> > Next step is the modification of
>> > ParaView\Servers\ServerManager\CMakeLists.txt. I have added
>> > vtkIOPython and vtkRenderingPython to KIT_PYTHON_LIBS (Line 157). This
>> > tells linker where to find some additional functions.
>> >
>> > This solution worked until recently. I had been able to use ParaView
>> > classes together with all VTK classes.
>> >
>> > Now I'm receiving exception:
>> > vtkProcessModuleConnectionManager: Invalid connection ID: 4
>> >
>> > When I debug, it seems there is no Interactor created inside
>> > SMRenderModuleProxy ...
>> >
>> > I suspect, it is some compilation related mess caused by my unclear
>> > "solution". If so, you'll probably be unable to give me any help with
>> > that.
>> >
>> > Just a quick question, is there any special reason to have some "light
>> > weight" version of VTK Python wrapper especially for ParaView, instead
>> > of "full featured" VTK Python wrappers?
>> >
>> > I'm thinking now, to simply add some extra modules to the ParaViews
>> > vtkCommonPython could be the right solution for me ...
>> >
>> > Thanks,
>> > Milan.
>> >
>> > On 8/3/06, Utkarsh Ayachit <utkarsh.ayachit at kitware.com> wrote:
>> >> Hi Milan,
>> >>
>> >> Can you please elaborate what was your "previous solution" and what 
>> are
>> >> the difficulties that you facing due to the new changes? If I remember
>> >> correctly, the only thing that changed was adding of a bunch of more
>> >> classes to vtkCommonPython (apart from "paraview") python module.
>> >>
>> >> Utkarsh.
>> >>
>> >> Milan Frank wrote:
>> >> > Hi All,
>> >> >
>> >> > I'm working with ParaView Python interface. I can see that quite 
>> a lot
>> >> > of changes has been made recently in this area. Because of this, I'm
>> >> > in serious troubles now.
>> >> >
>> >> > Due to wxPython cooperation I was in need to employ full scale vtk
>> >> > python wrappers instead of the minimized ParaView version called
>> >> > vtkCommonPython.
>> >> >
>> >> > After the latest CVS update I'm unable to re-do my previous solution
>> >> ...
>> >> >
>> >> > Could anyone suggest some way how to get rid of the ParaViews
>> >> > vtkCommonPython and use these VTKs Python libraries?
>> >> >
>> >> > Thank you in advance,
>> >> > Milan
>> >> > _______________________________________________
>> >> > ParaView mailing list
>> >> > ParaView at paraview.org
>> >> > http://www.paraview.org/mailman/listinfo/paraview
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>