[Paraview-developers] Writing a plugin : questions
Jean-Noël Chiganne
jean-noel.chiganne at limsi.fr
Wed Apr 25 08:05:09 EDT 2012
Thanks a lot Sebastien !
Regards,
Jean-Noël
2012/4/25 Sebastien Jourdain <sebastien.jourdain at kitware.com>
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20120425/79d4a065/attachment-0001.htm>
More information about the Paraview-developers
mailing list