[PD-dev] bug when redrawing gop within gop inside a closed sub-patch

[Mathieu Bouchard]

On Thu, 19 Nov 2009, Ivica Ico Bukvic wrote:

> So, if anyone is aware of the reason for its placement, it would be most 
> helpful to learn more about that before making the final decision 
> whether to keep/remove it.

Because objectboxes and messageboxes and atomboxes have become opaque, so 
the stacking order of wires does matter more. They have to stay on top in 
order to be more visible, yet the pd architecture is not sophisticated 
enough to allow pd to force all of its externals to draw all boxes _under_ 
the wires.

> What things like "&x->x_obj.te_gobj.g_pd" (to use your example) mean (e.g.
> struct structure and function of g_pd vs. te_gobj vs. x_obj etc.)

You can look those up in <m_pd.h>. What kind of comment are you looking 
for? Where would they be placed? Suppose you are reading one function in 
particular. Where would be the comment that refers to the meaning of 
&x->x_obj.te_gobj.g_pd ?

In any case, the deepest meaning of &x->x_obj.te_gobj.g_pd as it could be 
documented is:

   /* I should have learned C++ */

> Unless I am mistaken (and please do correct me if I am wrong) this call 
> is for both mapping and unmapping, yet the description suggests it is 
> about mapping only.

send your comments to Miller and see whether he cares.

> All that said, I may have very well missed something, so if there is a 
> good resource that shows the code tree and basic API information, that 
> would be certainly very helpful and most appreciated.

Martin Peach wrote the most complete doc of the internals, but I don't 
recall whether it covers that or not.

> If it makes it more legible without breaking the code, I am all for it.

Ok. Well, I did something like that in my branch, but that requires C++ 
and defining CPLUSPLUS_FACE before including <m_pd.h>.

> I would love to contribute more, but time is a precious commodity we are 
> all short on. So, for the sake of making contributions easier, IMHO I 
> think it would be a great idea to overhaul the code to the point where 
> it is possible to make such contributions much more efficiently. I am 
> hoping that this is what Hans is trying to do with the gui rewrite.

Why hope?... "Rewrite" is just another name for not rewriting, "GUI" is 
just another name for less than half of the GUI, and hope is all too often 
a disease that makes one stand still.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801