[Paraview] Behavior of a plugin reader that shares the same proxy name as one of the internal readers?

Takuya OSHIMA oshima at eng.niigata-u.ac.jp
Fri Aug 24 11:15:24 EDT 2012


Addendum: you have to put the representation plugin under
PV_PLUGIN_PATH to auto-load. Strangely, if I check "Auto Load" in the
Plugin Mnager to auto-load, the problem does not reproduce.

Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN


From: Takuya OSHIMA <oshima at eng.niigata-u.ac.jp>
Subject: Re: [Paraview] Behavior of a plugin reader that shares the same proxy name as one of the internal readers?
Date: Fri, 24 Aug 2012 23:51:55 +0900 (JST)

> Hi Utkarsh,
> 
> It looks like there is a problem in the order of loading internal
> proxies (vtkPVInitializerPlugin?) and user plugins. I get the
> aforementioned crash when I auto-load the plugin under (application
> dir)/plugins but do not when I load manually from the Plugin Manager.
> 
> The problem affects not only my tricky plugin but also user plugins
> that inherit internal proxies by base_proxyname="..." or <Extension
> />. Try ParaView/Examples/Plugins/Representation of the git-master. It
> works (I can choose the "Special Mapper" representation for a
> polygonal dataset) if manually loaded, but if auto-loaded it complains
> vtkSIProxyDefinitionManager (0x119f75690): Extension for (representations, GeometryRepresentation) ignored since could not find core definition.
> 
> If I am not mistaken there has been changes like the removal of
> vtkParaViewIncludeModulesToSMApplication and the introduction of
> vtkPVInitializerPlugin mechanism after 3.14.1 so I think my
> observation could be consistent with the internal change.
> 
> Takuya OSHIMA, Ph.D.
> Faculty of Engineering, Niigata University
> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
> 
> From: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
> Subject: Re: [Paraview] Behavior of a plugin reader that shares the same proxy name as one of the internal readers?
> Date: Mon, 20 Aug 2012 09:40:46 -0400
> 
> > Takuya,
> > 
> > I am surprised it worked in 3.14. I don;t think there has been much
> > change in the ServerManager since 3.14. I could track down what change
> > caused it, but nonetheless, I think it's probably not a good idea to
> > override default proxy. You should just create a new one with a new
> > name and still assign to the same extensions. The user will be
> > presented a dialog to pick which reader to create when he opens a
> > matching extension file. That way state files/python scrips referring
> > to one or the other will continue to work seamlessly without one
> > accidentally creating the other one, etc.
> > 
> > BTW, is there are newer version of the OpenFOAM reader that needs to
> > go into ParaView for the upcoming release?
> > 
> > Utkarsh
> > 
> > On Sun, Aug 19, 2012 at 3:00 AM, Takuya OSHIMA
> > <oshima at eng.niigata-u.ac.jp> wrote:
> >> Hi,
> >>
> >> My reader plugin shares the same name as one of the builtin readers of
> >> ParaView (OpenFOAMReader), as shown in the following server side XML.
> >>
> >> <ServerManagerConfiguration>
> >>   <ProxyGroup name="sources">
> >>     <SourceProxy name="OpenFOAMReader" class="vtkPOFFDevReader">
> >> ....
> >>
> >> If my memory serves me right I read in this list that a plugin has
> >> precedence over an internal object in searching for a proxy. Indeed,
> >> in the past released versions of ParaView (including 3.14.1), the
> >> plugin reader has worked well in overriding the internal
> >> reader. However, with the git-master of ParaView (as of today), when I
> >> open an OpenFOAM case, the constructor of my reader panel (derived
> >> from pqAutoGeneratedObjectPanel) gets executed but "this->proxy()"
> >> picks up the proxy for the internal reader. I wonder if this is a
> >> design change?
> >>
> >> Takuya OSHIMA, Ph.D.
> >> Faculty of Engineering, Niigata University
> >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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


More information about the ParaView mailing list