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

[Takuya OSHIMA]

I tested the fix and it did the trick. Thank you!

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: Wed, 5 Sep 2012 14:19:21 -0400

> 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
> <oshima at eng.niigata-u.ac.jp> 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 <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
>> _______________________________________________
>> 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