[PD-dev] canvas_* functions and using glist_getcanvas()

[Hans-Christoph Steiner]

Likewise:

http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revision=13715
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revision=13716
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revision=13717

.hc

On Jul 14, 2010, at 4:33 PM, Miller Puckette wrote:

> Ok .. commited and pushed to SF...
> On Wed, Jul 14, 2010 at 04:18:32PM -0400, Hans-Christoph Steiner  
> wrote:
>>
>> Ok, keep me posted.  If that turns out to be wrong, I can change it  
>> in
>> a lot of externals in SVN too.
>>
>> .hc
>>
>> On Jul 14, 2010, at 4:11 PM, Miller Puckette wrote:
>>
>>> I think those are all wrong and will try changing them over here :)
>>>
>>> thanks
>>> M
>>>
>>> On Wed, Jul 14, 2010 at 04:07:16PM -0400, Hans-Christoph Steiner
>>> wrote:
>>>>
>>>> Sounds like you are saying that calls to canvas_fixlinesfor()
>>>> shouldn't have calls to glist_getcanvas() in them.  It seems not  
>>>> very
>>>> straightforward, for example, the iemguis included in Pd-vanilla  
>>>> have
>>>> this:
>>>>
>>>> canvas_fixlinesfor(glist_getcanvas(x->x_gui.x_glist), (t_text*)x);
>>>>
>>>> .hc
>>>>
>>>> On Jul 14, 2010, at 3:15 PM, Miller Puckette wrote:
>>>>
>>>>> I think glist_getcanvas() is only appropriate when getting or
>>>>> changing
>>>>> properties that are inherited from the containing canvas (whether
>>>>> visible
>>>>> or not, for example) -- and many canvas_whatever(canvas, object)  
>>>>> or
>>>>> glist_whatever(canvas, object) calls assume tha the oject is  
>>>>> indeed
>>>>> in that
>>>>> glist itself (glist is synonym for canvas) and will crash if not.
>>>>>
>>>>> cheers
>>>>> Miller
>>>>>
>>>>> On Wed, Jul 14, 2010 at 01:17:41PM -0400, Hans-Christoph Steiner
>>>>> wrote:
>>>>>>
>>>>>> I've noticed that in GUI objects, its quite common to call the
>>>>>> canvas_* functions using glist_getcanvas().  I also just found  
>>>>>> out
>>>>>> that this causes a crash in [envgen] when this is done for
>>>>>> canvas_deletelinesfor().  See bug:
>>>>>>
>>>>>> http://sourceforge.net/tracker/index.php?func=detail&aid=2842897&group_id=55736&atid=478070
>>>>>>
>>>>>> So it seems to me that glist_getcanvas() should not be called on
>>>>>> the
>>>>>> glist before sending it to one of these canvas functions.  I was
>>>>>> wondering if this is kind of a blanket rule, and we should be
>>>>>> removing
>>>>>> the glist_getcanvas() calls in GUI objects.  For example:
>>>>>>
>>>>>> unauthorized/cooled~/cooled~.c:
>>>>>> canvas_deletelinesfor( glist_getcanvas(glist), (t_text *)z);
>>>>>> unauthorized/cooled~/cooled~.c:
>>>>>> canvas_fixlinesfor( glist_getcanvas( x->x_glist ), (t_text*)x );
>>>>>>
>>>>>> In ggee/gui/w_envgen.h, I fixed the crasher by replacing:
>>>>>>
>>>>>> canvas_deletelinesfor(glist_getcanvas(glist), x);
>>>>>>
>>>>>> with this:
>>>>>>
>>>>>> canvas_deletelinesfor(glist, x);
>>>>>>
>>>>>> .hc
>>>>>>
>>>>>> ----------------------------------------------------------------------------
>>>>>>
>>>>>> "Free software means you control what your computer does. Non- 
>>>>>> free
>>>>>> software means someone else controls that, and to some extent
>>>>>> controls
>>>>>> you." - Richard M. Stallman
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pd-dev mailing list
>>>>>> Pd-dev at iem.at
>>>>>> http://lists.puredata.info/listinfo/pd-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------------
>>>>
>>>> 'You people have such restrictive dress for women,? she said,
>>>> hobbling
>>>> away in three inch heels and panty hose to finish out another pink-
>>>> collar temp pool day.  - ?Hijab Scene #2", by Mohja Kahf
>>>>
>>
>>
>>
>>
>>
>> ----------------------------------------------------------------------------
>>
>> Programs should be written for people to read, and only incidentally
>> for machines to execute.
>> - from Structure and Interpretation of Computer Programs
>>
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev



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

If you are not part of the solution, you are part of the problem.