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

[Utkarsh Ayachit]

Ah! I cannot tell how much I abhor PV_PLUGIN_PATH. I wonder how many
people will scream if I took out support for it :/. I'll see if I can
cleanup the PV_PLUGIN_PATH init stuff while I am at it.

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