[Paraview-developers] plugin to simplify ParaView UI - selection by node # and pqSelectionInspectorPanel issues

[pat marion]

Hi Jon,

Is there a requirement that this can't depend on python?  Any
selection object that the pqSelectionInspectorPanel can create can be
created with python and the paraview python api.  This is used a lot
in the pvblot plugin (Plugins/pvblot/tplot.py for example)

Paraview has the ability to dynamically create toolbar buttons mapped
to python routines (python scripts actually), or if you want something
with a more customized interface you can write a Qt plugin to
implement the UI but under the hood all it needs to do is call python
routines.  Calling python from c++ is made quite easy by the class
pqPythonDialog (accessible to plugins thru the pqPythonManager).

Pat

On Mon, Oct 26, 2009 at 7:22 PM, Goldman, Jon <jgoldma at sandia.gov> wrote:
> I am looking for feedback on the "right" way to proceed in solving a particular problem inside a plugin.
>
> I am working on a plugin for a group at Sandia whose members want to be able to run certain ParaView operations, but do them quickly from a simplified user interface, i.e. a plugin toolbar. For example they may want to do these steps:
>  - Open an exodus file
>  - Select nodal variable DISPL
>  - Select specific points/nodes by number, by typing in these GlobalIDs: 100,113, and 270
>  - Plot the selected points/nodes over time
>
> ParaView's Selection Inspector, pqSelectionInspectorPanel class, has functionality that accomplishes much or all of what I would need to satisfy user requirements.
>
> I see these possible paths:
> a) Re-use the Selection Inspector pqSelectionInspectorPanel object that gets created when ParaView starts;
> b) Inherit from pqSelectionInspectorPanel, and override methods I need for customization, create and manage my own object instance;
> c) Borrow and Re-write source code from pqSelectionInspectorPanel, and implement needed functionality inside my plugin;
> d) I am missing something, and there is a more elegant way.
>
> I like the idea of (a), because in theory if the user uses the standard ParaView GUI, or my plugin toolbar, the pqSelectionInspectorPanel will stay consistent, making it easier to keep the state of ParaView and the plugin in sync.
>
> Option (b) would not be too bad, because I'd be re-using more ParaView code, and getting code changes if somebody updates the pqSelectionInspectorPanel class. Drawbacks - there would be multiple in-core instances of pqSelectionInspectorPanel, and it would be harder to keep the plugin UI and ParaView UI in sync, and maybe there are some Qt or pQ difficulties I am not aware of.
>
> One question-- is (a) possible (or advisable) with today's ParaView architecture/source code?
> I was looking through pqMainWindowCore where the pqSelectionInspectorPanel gets created:
>  void pqMainWindowCore::setupSelectionInspector(QDockWidget* dock_widget)
>  {
>    pqSelectionInspectorPanel* const selection_inspector =
>      new pqSelectionInspectorPanel(dock_widget)
>      << pqSetName("selectionInspectorPanel");
>    .
>    .
>    .
>  }
> Does a plugin have access to pqMainWindowCore and the pqSelectionInspectorPanel objects?
>
> Option (c) introduces code maintenance, and other issues, but perhaps is best-under-the-circumstances way to proceed...?
>
> And of course I welcome (d) if somebody has other good ideas  :-)
>
> -Jon
>
>
> _______________________________________________
> Paraview-developers mailing list
> Paraview-developers at paraview.org
> http://public.kitware.com/mailman/listinfo/paraview-developers
>