Re: [Fresco-devel] Bogus traversals (and patch)

Stefan Seefeld wrote:
> What you outline is not how it works. I hope the following can make this
> clear:
> 
> Assume a graph with parent node 'A' and child node 'B'. You call
> A->traverse(t);
> 
> which results in
> 
> t->visit(A);
> 
> which results in
> 
> A->draw(t);

Nick Lewycky wrote:
>> The bug is that some graphics will go through their children instead 
>> of going back through the Traversal's traverse_child function. If the 
>> Traversal never calls draw or pick, then it will never be able to 
>> traverse that part of the tree!
> 
> that's right, 'draw' and 'pick' are the only implemented traversals right
> now. But I don't see how this could be made differently. You are talking
> about 'going back through the Traversal's traverse_child function'. How
> can that work ? How do you know (outside the polymorphic 'draw' or 'pick')
> that this graphic has children ?

I ask the graphic to traverse itself, then its children by calling 
A->traverse(t);

My suggested implementation of A->traverse(t) is {t->visit(_this); 
MonoGraphic::traverse(t); }

 > That's where the attributes are set (if A is an RGBDecorator). Now if
 > you return directly, the traversal has no idea that 'A' is a
 > mono-graphic, i.e. that there is a child graphic to traverse. Thus 'A'
 > has to do that inside its 'draw' method. Since RGBDecorator derives
 > from MonoGraphic, and since MonoGraphic::traverse does just that, we
 > only need to call
 >
 > MonoGraphic::traverse(t);
 >
 > inside A::draw, while the DrawingKit attributes are changed. That will
 > trigger the subgraph to be traversed. Once that is done, we restore
 > the attributes, and return.

My suggested implementation of A::draw never restores the attributes.

Instead, the DrawTraversal is stuck with that role, calling 
drawing->save() once before A->draw(t) and drawing->restore() once 
after. Thusly, the children are traversed with the attributes set by the 
RGBDecorator.

Nick Lewycky