[Paraview-developers] Writing a plugin : questions
Sebastien Jourdain
sebastien.jourdain at kitware.com
Wed Apr 25 08:03:30 EDT 2012
Hi Jean-Noel,
The documentation is basically in the header file of
vtkSMSessionProxyManager and vtkSMProxy that I've just pasted below as
the formatting of it get messed up in the online doxygene
documentation.
Otherwise, you may get some other informations on the wiki here:
- http://paraview.org/Wiki/ServerManager_XML_Hints
Seb
=== vtkSMSessionProxyManager ===
// Basic XML Proxy definition documentation:
//
// ------------- Proxy definition -------------
// <SourceProxy => Will create vtkSM + SourceProxy class
// name="SphereSource" => Key used to create the proxy
// class="vtkSphereSource" => Concreate vtkClass that do the real job
// label="Sphere"> => Nice name used in menu and python shell
//
// ----------- Property definition -----------
// <DoubleVectorProperty => Will create vtkSM + DoubleVectorProperty
// and vtkSI + DoubleVectorProperty class by
// default.
// name="Center" => Name of the property:
// vtkPropertyHelper(proxy,
"Center").Set(0,1,2)
// command="SetCenter" => Real method name that will be called on
// vtkObject when the property will
be updated.
// number_of_elements="3" => Size of the vector
// animateable="1" => Tell the animation view that property
// can be used as an evolving property
// default_values="0 0 0"> => The value that will be set at the
// </DoubleVectorProperty> construction to the VTK object
// </SourceProxy>
//
// For custom behaviour the user can add some extra attributes:
//
// - We can specify a custom SIProperty class to handle in a custom way the
// data on the server.
// <StringVectorProperty => vtkSMStringVectorProperty class
// name="ElementBlocksInfo" => Property name
// information_only="1" => Can only be used to fecth data
// si_class="vtkSISILProperty" => Class name to instanciate on
the other side
// subtree="Blocks"/> => Extra attribute used by
vtkSISILProperty
//
// - We can trigger after any update a command to be executed
// <Proxy name="LookupTable"
// class="vtkLookupTable"
// post_push="Build" => The method Build() will be called each
// time a new property value is pushed to
// the VTK object.
// processes="dataserver|renderserver|client" >
//
// - We can force any property to push its value as soon has it get changed
// <Property name="ResetFieldCriteria"
// command="ResetFieldCriteria"
// immediate_update="1"> => Modifying the property will result
// of a push of it and the execution
// of the command on the vtkObject.
//
// - To show a source proxy or a filter inside the menu of ParaView
we use a hint
// <SourceProxy ...>
// <Hints>
// <ShowInMenu => The category attribute allow to
// category="PersoFilter"/> specify in which sub-menu this
// proxy should be in. (optional)
// </Hints>
// </SourceProxy>
==== vtkSMProxy ===
// vtkSMProxy manages VTK object(s) that are created on a server
// using the proxy pattern. The managed object is manipulated through
// properties.
// The type of object created and managed by vtkSMProxy is determined
// by the VTKClassName variable. The object is managed by getting the desired
// property from the proxy, changing it's value and updating the server
// with UpdateVTKObjects().
// A proxy can be composite. Sub-proxies can be added by the proxy
// manager. This is transparent to the user who sees all properties
// as if they belong to the root proxy.
//
//
// When defining a proxy in the XML configuration file,
// to derrive the property interface from another proxy definition,
// we can use attributes "base_proxygroup" and "base_proxyname" which
// identify the proxy group and proxy name of another proxy. Base interfaces
// can be defined recursively, however care must be taken to avoid cycles.
//
// There are several special XML features available for subproxies.
// \li 1) It is possible to share properties among subproxies.
// eg.
// \code
// <Proxy name="Display" class="Alpha">
// <SubProxy>
// <Proxy name="Mapper" class="vtkPolyDataMapper">
// <InputProperty name="Input" ...>
// ...
// </InputProperty>
// <IntVectorProperty name="ScalarVisibility" ...>
// ...
// </IntVectorProperty>
// ...
// </Proxy>
// </SubProxy>
// <SubProxy>
// <Proxy name="Mapper2" class="vtkPolyDataMapper">
// <InputProperty name="Input" ...>
// ...
// </InputProperty>
// <IntVectorProperty name="ScalarVisibility" ...>
// ...
// </IntVectorProperty>
// ...
// </Proxy>
// <ShareProperties subproxy="Mapper">
// <Exception name="Input" />
// </ShareProperties>
// </SubProxy>
// </Proxy>
// \endcode
// Thus, subproxies Mapper and Mapper2 share the properties that are
// common to both; except those listed as exceptions using the "Exception"
// tag.
//
// \li 2) It is possible for a subproxy to use proxy definition
defined elsewhere
// by identifying the interface with attribues "proxygroup" and "proxyname".
// eg.
// \code
// <SubProxy>
// <Proxy name="Mapper" proxygroup="mappers" proxyname="PolyDataMapper" />
// </SubProxy>
// \endcode
//
// \li 3) It is possible to scope the properties exposed by a subproxy
and expose
// only a fixed set of properties to be accessible from outside. Also,
// while exposing the property, it can be exposed with a different name.
// eg.
// \code
// <Proxy name="Alpha" ....>
// ....
// <SubProxy>
// <Proxy name="Mapper" proxygroup="mappers"
proxyname="PolyDataMapper" />
// <ExposedProperties>
// <Property name="LookupTable" exposed_name="MapperLookupTable" />
// </ExposedProperties>
// </SubProxy>
// </Proxy>
// \endcode
// Here, for the proxy Alpha, the property with the name
LookupTable from its
// subproxy "Mapper" can be obtained by calling
GetProperty("MapperLookupTable")
// on an instance of the proxy Alpha. "exposed_name" attribute is
optional, if
// not specified, then the "name" is used as the exposed property name.
// Properties that are not exposed are treated as
// non-saveable and non-animateable (see vtkSMProperty for details).
// Exposed property restrictions only work when
// using the GetProperty on the container proxy (in this case Alpha) or
// using the PropertyIterator obtained from the container proxy. If one
// is to some how obtain a pointer to the subproxy and call GetProperty on
// it (or get a PropertyIterator for the subproxy), the properties exposed
// by the container class are no longer applicable.
// If two exposed properties are exposed with the same name, then
a Warning is
// flagged -- only one of the two exposed properties will get exposed.
//
// .SECTION See Also
// vtkSMProxyManager vtkSMProperty vtkSMSourceProxy vtkSMPropertyIterator
On Wed, Apr 25, 2012 at 3:09 AM, Jean-Noël Chiganne
<jean-noel.chiganne at limsi.fr> wrote:
> Hi Nikhil,
>
> Thanks for your answer !
>
> So I'll continue my investigations in the VR plugin and do what you suggest
> about extending it.
>
> When you say "Extend the internal event structure to include OSC data.", do
> you mean the internal event structure of ParaView or of the VR plugin ?
>
> If someone has a link, I'm still looking for a doc about the XML
> ServerManager syntax. =)
>
> Have a good day,
>
> Jean-Noël
>
> 2012/4/24 Nikhil Shetty <nikhil.shetty at kitware.com>
>>
>> Hi Jean,
>>
>> The VRPlugin simply provides a framework to pass alternative event
>> streams. It currently takes VRPN and/or VRUI streams and converts it into an
>> internal event structure. There is a dispatcher which takes these event
>> streams and dispatches to various VRInteractor styles.
>>
>> However the even stream does not replace the window interactor but instead
>> we define new interactor styles which work alongside the current style.
>>
>> You could start writing the plugin from scratch by copying the VRPlugin
>> over and deleting unnecessary classes. Alternatively you could extend the
>> plugin cause it has most of the framework to forward (non native) events to
>> the system.
>>
>> If you decide to do the latter then you will have to do the following
>>
>> 1. Add a connection client for OSC (VRPN and VRUI are just connection
>> clients).
>> 2. Extend the internal event structure to include OSC data.
>> 3. Write an Interactor style to handle OSC events.
>>
>> All the best
>>
>> Regards
>> Nikhil
>>
>> On Tue, Apr 24, 2012 at 9:13 AM, Jean-Noël Chiganne
>> <jean-noel.chiganne at limsi.fr> wrote:
>>>
>>> Hi all,
>>>
>>> I'm trying to develop a plugin in Paraview and I have some questions.
>>> I found a wiki page "PlugIn How To" speaking a little about plugin
>>> implementation but it's still confuse to me.
>>>
>>> Is there a page explaining all the XML syntax of the ServerManager and
>>> ClientManager files ? For instance I tried to compile and use the plugin
>>> "MyView" as shown on the wiki page, but I've got an error message when
>>> loading it in Paraview "Failed to create a proxy for the requested view
>>> type...". As I don't know the XML syntax it's hard to find where the mistake
>>> could be.
>>>
>>> I have an other question. My goal is to develop a plugin which would make
>>> paraview reactive to OSC messages (or VRPN messages, I've seen there is a VR
>>> plugin but it's another problem ^^) but I don't know if it's possible ?
>>> Actually I don't understand where is the entry point for paraview in the C++
>>> source code of a plugin, and how I can get back Paraview objects instances
>>> (as the render windows to get the camera and control it with OSC messages
>>> etc). To sum up, I think the final goal is to replace WindowInteractor by an
>>> Interactor reacting to OSC events instead of keyboard/mouse events.
>>>
>>> I hope my message is understandable ^^
>>>
>>> Thank you for reading :)
>>>
>>> Jean-Noël Chiganne
>>>
>>> _______________________________________________
>>> Paraview-developers mailing list
>>> Paraview-developers at paraview.org
>>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>>
>>
>
>
> _______________________________________________
> Paraview-developers mailing list
> Paraview-developers at paraview.org
> http://public.kitware.com/mailman/listinfo/paraview-developers
>
More information about the Paraview-developers
mailing list