[Paraview] qvtk problems with the pipeline

[Clinton Stimpson]

On 08/01/2009 05:01 AM, Dominik Szczerba wrote:
> Many thanks for the feedback. Pls see below:
>
> Clinton Stimpson wrote:
>> Dominik Szczerba wrote:
>>> My pipeline works all right and gets updated on demand properly. I 
>>> achieve it by connecting spinboxes/lineedits etc. to functions that 
>>> set parameters of my filters before I explicitly hit the final 
>>> 'apply' button. The annoying problem is that the pipeline gets 
>>> executed also when I interact with the render window (click to 
>>> rotate etc.). I did not (intend to) set up such functionality, I 
>>> want the pipeline to execute only after an explicit button click 
>>> (like in paraview). How do I find out who is triggering the pipeline 
>>> behind my back?
>>>
>>> - Dominik
>>>
>> ParaView queues up the changes, and only applies them to the filters 
>> when the apply button is pressed.
>> If you're applying them on the filters when spinboxes/lineedits 
>> change, and a menu comes and goes over the graphics view, that could 
>> trigger an update you might not want.
>>
>> How about your apply button gathering the parameters from the widgets 
>> on the form and applying them?
>
> That was my original idea and implementation: However, this way the 
> WHOLE pipeline ALWAYS gets re-executed. Concrete example pipeline: 
> extractVOI->GaussianSmooth. If Apply button gathers the parameters and 
> sets them to the filters every time, changing e.g. only smoothing 
> params (while keeping the same VOI) still causes both filters to 
> re-execute. This should not happen, as VOI should be up to date. The 
> same is true for more filters, e.g. Threshold: re-feeding the same 
> parameters and/or arrays to process somehow fools the up-to-date'ness 
> of the filter. Am I expected to walk around the problem by bookkeeping 
> the changing params and the up-to-date'ness myself?
>
> Note that this is different to paraview, where you have only one 
> filter per menu entry and can explicitly request changes. Here I have 
> one meta-filter, consisting of several atomic ones.
>
> After your remark I feel the original approach was the right one. But 
> then how do I only request the update if a REAL CHANGE and not only a 
> FORMAL SET of parameters is the case?
>

vtkSetMacro checks for changes before calling this->Modified();  But are 
you saying its a problem because not all Set functions check for changes?

To do your own bookkeeping, one idea is to connect to the QWidget's user 
property's notify signal (see QMetaObject::userPropery), and anytime one 
of those fires, you add to a list of widgets that have changed.  Then at 
apply time, just push those values down.

Clint