Thanks for the details. Helped me track down the issue in no time. Here the bug: http://paraview.org/Bug/view.php?id=13427
Utkarsh On Fri, Aug 24, 2012 at 11:15 AM, Takuya OSHIMA <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> >> 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 >> > <[email protected]> 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 > _______________________________________________ > 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
