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
