[PD-dev] pd vanilla/extended bug

[Hans-Christoph Steiner]

That's a tough one.  I made a simpler version of your bug patch with  
directions.  But I agree, there is a lot of potential to GOP, but only  
if it is rock-solid.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.pd
Type: application/octet-stream
Size: 711 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20091121/c85d0de0/attachment.obj>
-------------- next part --------------



.hc

On Nov 19, 2009, at 3:31 PM, Ivica Ico Bukvic wrote:

> All right. So, I've done some digging on this one and found out the
> following:
>
> The bug affects all versions of Pd and behaves even worse in 0.43
> extended. Given that Pd is all about abstracting one's work, I would
> consider this a high-priority bug.
>
> Basically it has to do with having a GOP-enabled sub-patch that has
> another GOP-enabled sub-patch visible within its parent GOP.
>
> Problems:
> 1) when turning off GOP on the parent subpatch through which you can  
> see
> child GOP-enabled sub-patch, after applying settings, the parent
> sub-patch converts to a regular object but clicking on it does nothing
> and results in console errors like this:
>
> bad window path name ".x9e91188"
> bad window path name ".x9e91188.c"
> bad window path name ".x9e91188"
> bad window path name ".x9e91188"
> bad window path name ".x9e91188.c"
> bad window path name ".x9e91188"
>
> Doing the same while the child sub-patch is visible has no negative
> effect. See below patch for example (open [pd test] sub-patch and
> disable GOP in the pd parent-tester or whatever its name) and then try
> opening it.
>
> 2) when the same happens, there are sometimes stray objects left that
> were previously visible through GOP rectangle. they cannot be  
> interacted
> with and are just leftover graphics. This is the case with both  
> vanilla
> and pd-extended.
>
> 3) the problem also exists if you want to change the number on the  
> main
> patch (provided below) that sends data to tester-child. This will  
> result
> in similar errors on the console. This one affects only pd-extended  
> and
> the offending line is in g_editor.c function gobj_shouldvis (around  
> line
> 84):
>
> sys_vgui(".x%lx.c raise all_cords\n", glist_getcanvas(glist));
>
> This should be commented out as it is not present in vanilla version  
> and
> is causing the problem I described in my earlier email.
>
>
> Please see patch below:
>
> #N canvas 265 330 294 205 10;
> #X obj 115 76 s test;
> #N canvas 696 341 288 186 tester 0;
> #N canvas 16 267 440 290 tester-parent 0;
> #N canvas 5 125 450 300 tester-child 0;
> #X obj 113 29 r test;
> #X floatatom 124 117 5 0 0 0 - - -;
> #X msg 130 60 set \$1;
> #X connect 0 0 2 0;
> #X connect 2 0 1 0;
> #X coords 0 -1 1 1 85 60 1 100 100;
> #X restore 132 112 pd tester-child;
> #X coords 0 -1 1 1 150 90 1 100 100;
> #X restore 67 58 pd tester-parent;
> #X coords 0 0 1 1 300 80 0;
> #X restore 108 112 pd tester;
> #X floatatom 113 41 5 0 0 0 - - -;
> #X connect 2 0 0 0;
>
> Any ideas how to tackle this one? Seems like a real pickle to me...
>
> Ico
>



----------------------------------------------------------------------------

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.  Now that he can realize them, he must either  
change them, or perish.    -William Carlos Williams