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

Hans-Christoph Steiner hans at at.or.at
Sat Nov 21 06:39:03 CET 2009


On Nov 20, 2009, at 3:14 PM, Mathieu Bouchard wrote:

> 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.

Well, its easy enough to raise all wires.  That's what Pd-extended  
does, but there are a couple bugs with that...

.hc

>
>> 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_______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev


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

Access to computers should be unlimited and total.  - the hacker ethic






More information about the Pd-dev mailing list