Re: [Paraview] custom view plugin - minimal example needed

[Artem Bodrin]

Hello, dear participants.

Actually, one can do what Kolja needs. If you are still interested, I can 
deduce the sample from my plugin.

In 2 words: 
1) inherit main view class MyView from pqView
2) create a stub class vtkPVMyView, inherited from vtkPVView, override pure 
virtual functions
3) add to plugin's XML:










4) create your own container widget class and return it from 
MyView::createWidget() method
5) use this in your plugin’s CMakeLists.txt:

   add_pqproxy(
  VIEW_IFACE VIEW_IFACE_SRCS
  TYPE MyView
  XML_GROUP views
  XML_NAME MyView
   )

That’s it. I used SpreadSheet view implementation for inspiration.


> 27 янв. 2018 г., в 15:17, Kolja Petersen  написал(а):
> 
> Thank you Mathieu, your answer helped me decide whether to continue our 
> developments based on Paraview.
> Kolja
> 
>  
> 
> Virenfrei. www.avast.com 
> 
>  
> 
> On Fri, Jan 26, 2018 at 9:26 AM, Mathieu Westphal 
> > wrote:
> Hi Kolja
> 
> Inheriting directly from vtkPVView is not possible as there is specific code 
> dedicated to managing each type of base view. Even if it was possible, it 
> would not allow you to add QtWidget anywhere in the view.
> This is not possible due to design.
> However, there are possibilities to add Qt widgets in the properties panel, 
> in the view tool items and in any dedicated QDockWidget or QToolbar you may 
> want to add in your plugin.
> 
> Also please keep in mind this mailing list is a volontary Q, We do offer 
> consulting services [1] if you want to work with ParaView development team 
> directly.
> 
> Best,
>  
> 
> Mathieu Westphal
> 
> [1] https://www.kitware.com/what-we-offer/#consulting 
> 
> 
> On Fri, Jan 26, 2018 at 7:31 AM, Kolja Petersen  > wrote:
> Dear Mathieu,
> I may be missing the point of your suggested code. I asked whether plugins 
> can provide views beyond the existing RenderViews, on 15 January I sent a 
> code snippet to the list to show my successful attempts that implement a new 
> RenderView and ask how to replace it with a generic view containing other Qt 
> widgets, and now you reproduced another version of the functionality from my 
> snippet.
> 
> Why?
> 
> 
> On Tue, Jan 23, 2018 at 10:45 AM, Mathieu Westphal 
> > wrote:
> Hello
> 
> Here is a minimal example for creating a new type of view within a plugin.
> You actually cannot inherit directly from vtkPVView, you must inherit for a 
> base view, which can be :
>  - vtkPVRenderView
>  - vtkPVContextView
>  - vtkPythonView
>  - vtkSpreadSheetView
> (https://www.paraview.org/ParaView/Doc/Nightly/www/cxx-doc/classvtkPVView.html
>  
> )
> 
> This choice is also visible in the associated xml files where you precise 
> which kind of proxy you want to create.
> 
> In the attached example, I demonstrated how to add a clone of the Render 
> View, called Render View 2.
> 
> Hope it helps,
> 
> Best,
> 
> 
> Mathieu Westphal
> 
> On Mon, Jan 22, 2018 at 7:08 PM, Kolja Petersen  > wrote:
> Thank you, Mathieu,
> any update on this?
> All my research seems to point to a few hardcoded views that are accessible. 
> I simply can't find a solution to implement a new view and open it from a 
> plugin.
> Thanks
> Kolja
> 
> 
> On Wed, Jan 17, 2018 at 9:55 AM, Mathieu Westphal 
> > wrote:
> Hi Kolja
> 
> I have a simple view plugin project ongoing that I should be able to scale 
> down for your needs. 
> I will try to find the time to do it before the end fo the week.
> 
> Best, 
> 
> Mathieu Westphal
> 
> On Tue, Jan 16, 2018 at 8:38 PM, Kolja Petersen  > wrote:
> Is it possible to write a plugin that derives from vtkPVView instead of 
> vtkPVRenderView?
> 
> I don't know how I can further shorten my question. The answer is quite 
> important to decide whether we can continue our ParaView developments.
> Thank you
> Kolja
> 
>  
> 
> Virenfrei. www.avast.com 
> 
>  
> 
> 
> On Mon, Jan 15, 2018 at 7:32 PM, Kolja Petersen  > wrote:
> I have 

[Paraview] Multiple identical "sources" proxies in a saved XML state file (GlyphType)

[Artem Bodrin]

Hello, dear developers.

I have issued this question on a bug tracker, but will duplicate it here, if 
you do not mind
https://gitlab.kitware.com/paraview/paraview/issues/17957 
<https://gitlab.kitware.com/paraview/paraview/issues/17957>


I'm not sure if this is a bug, but I have noticed, that saved xml state file 
contains many identical proxies, that belongs to group "sources". These proxies 
are actual source proxies, and participating in property  of every saved 
"GeometryRepresentation" proxy. 

So every "GeometryRepresentation" have it's own bunch of GlyphType source proxy 
instances (listed in proxy_list Domain), and all of them are saved to a state 
file.

I can understand, that saving all of them can be explained by "unified 
approach" to saving proxy to state file, but I have trouble with resulting 
state file - we tracking it's change with VCS (git, if it matters), and so many 
unnecessary (cause they are identical, except GlobalId) proxies saved gives us 
additional pain.

As an additional side effect we have increased state loading time. This issue 
might be related to appearance of saved GlyphType proxies in a state file: 
https://gitlab.kitware.com/paraview/paraview/issues/17768

Please, correct me if I'm wrong, but one can not change the Domain type at 
runtime, so this proxy_list will be constant until changed in a 
views_and_representations.xml. If so, than maybe there is a way to save 
GlyphType proxies to state file only once (or not at all) and reference their 
GlobalIds from any other GeometryRepresentation?

Thanks in advance, 
Artem Bodrin.___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
https://paraview.org/mailman/listinfo/paraview