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

[Takuya OSHIMA]

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