[PD-dev] what does x->gl_editor represent?
Hans-Christoph Steiner
hans at at.or.at
Wed Jan 20 17:09:09 CET 2010
Ok, that makes sense. I've noticed in the code it seems there are some
places where a test for x->gl_editor assumes x->gl_havewindow is
true. That used to be the case, but no more if non-vised GOPs have a
gl_editor.
.hc
On Jan 20, 2010, at 12:27 AM, Miller Puckette wrote:
> i _think_ the gl_editor should be the GOP's own, not that of its
> parent.
> It's a structure parallel to that of the canvas itself, which supplies
> "rtext" memory space for each 'text' box in the canvas's gl_list list.
>
> cheers
> M
> On Tue, Jan 19, 2010 at 11:03:23PM -0500, Hans-Christoph Steiner
> wrote:
>>
>> Hey Miller,
>>
>> So I guess the part I don't get is which x->gl_editor should a GOP
>> have? A non-GOP abstraction that is not vised has no gl_editor,
>> while
>> a GOP abstractions/subpatch that is not vised does have a gl_editor
>> of
>> its own (i.e. the GOP has a gl_editor different from its parent when
>> not vised). For some reason, it seems to me that this non-vised GOP
>> should have the gl_editor of its parent.
>>
>> .hc
>>
>> On Jan 19, 2010, at 10:26 PM, Miller Puckette wrote:
>>
>>> Well, canvas_findrtext is expected always to succeed, and in order
>>> for it to
>>> succeed there has to be an 'editor'. Anyway, line 900 checked that
>>> there
>>> is indeed an 'editor' which means that 'if (!gl->gl_editor) ' is
>>> false
>>> so canvas_create_editor(gl) doesn't get called (I think).
>>>
>>> Anyhow, this is the second most complicated bit in Pd (the worst is
>>> canvas_deseltext()) and very, very hard to get working right.
>>>
>>> cheers
>>> M
>>>
>>> On Tue, Jan 19, 2010 at 07:15:16PM -0500, Hans-Christoph Steiner
>>> wrote:
>>>>
>>>> Ok, more info on this solo thread. So it turns out that
>>>> canvas_destroy_editor() calls glist_findrtext() which in turn calls
>>>> canvas_create_editor(). That doesn't seem to make a lot of sense.
>>>> It
>>>> seems that canvas_create_editor() should not be in
>>>> glist_findrtext().
>>>>
>>>> g_editor.c:
>>>> 896 void canvas_destroy_editor(t_glist *x)
>>>> 897 {
>>>> 898 t_gobj *y;
>>>> 899 t_object *ob;
>>>> 900 if (x->gl_editor)
>>>> 901 {
>>>> 902 for (y = x->gl_list; y; y = y->g_next)
>>>> 903 if (ob = pd_checkobject(&y->g_pd))
>>>> 904 rtext_free(glist_findrtext(x, ob));
>>>> 905 editor_free(x->gl_editor, x);
>>>> 906 x->gl_editor = 0;
>>>> 907 }
>>>> 908 }
>>>>
>>>> g_rtext.c:
>>>> 355 /* find the rtext that goes with a text item */
>>>> 356 t_rtext *glist_findrtext(t_glist *gl, t_text *who)
>>>> 357 {
>>>> 358 t_rtext *x;
>>>> 359 if (!gl->gl_editor)
>>>> 360 canvas_create_editor(gl);
>>>> 361 for (x = gl->gl_editor->e_rtext; x && x->x_text != who; x =
>>>> x->x_next)
>>>> 362 ;
>>>> 363 if (!x) bug("glist_findrtext");
>>>> 364 return (x);
>>>> 365 }
>>>>
>>>> .hc
>>>>
>>>> On Jan 19, 2010, at 5:54 PM, Hans-Christoph Steiner wrote:
>>>>
>>>>>
>>>>> I've been trying to figure out the whole t_editor/x->gl_editor
>>>>> thing. I've been writing things up here:
>>>>> http://wiki.puredata.info/en/t_editor
>>>>>
>>>>> It seems to me that there are lots of GOP bugs related to the fact
>>>>> that GOP glists now get a gl_editor assigned to them even when
>>>>> they
>>>>> are not [vis 1(. From what I can tell, there are lots of tests
>>>>> like
>>>>> if (x->gl_editor) which assume that the canvas/glist x -
>>>>>> gl_havewindow==1 if x->gl_editor == 1, which is no longer the
>>>>>> case
>>>>> as of 0.42.
>>>>>
>>>>> canvas_create_editor was added to glist_findrtext() in this
>>>>> commit:
>>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=10469
>>>>>
>>>>> .hc
>>>>>
>>>>> On Jan 15, 2010, at 5:13 PM, Hans-Christoph Steiner wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> so I guess here is my question, is this how things are supposed
>>>>>> to
>>>>>> work in terms of GOP:
>>>>>>
>>>>>> - when a GOP is drawn on the parent, gl_editor should be the same
>>>>>> as the parent's gl_editor
>>>>>> - when GOP is opened up, it gets its own gl_editor
>>>>>>
>>>>>> .hc
>>>>>>
>>>>>>
>>>>>> On Jan 15, 2010, at 4:44 PM, Hans-Christoph Steiner wrote:
>>>>>>
>>>>>>>
>>>>>>> I am trying to debug various issues with GOP and parent/child
>>>>>>> relationships. I am not quite clear on what x->gl_editor is
>>>>>>> supposed to be. Can anyone clue me in? The bug seems to be
>>>>>>> related to the fact that in canvas_vis(), pd doesn't quite know
>>>>>>> what x->gl_editor is supposed to be, since it changes....
>>>>>>>
>>>>>>> .hc
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------------------
>>>>>>>
>>>>>>> Mistrust authority - promote decentralization. - the hacker
>>>>>>> ethic
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------------
>>>>>>
>>>>>> Looking at things from a more basic level, you can come up with a
>>>>>> more direct solution... It may sound small in theory, but it in
>>>>>> practice, it can change entire economies. - Amy Smith
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------------
>>>>>
>>>>> News is what people want to keep hidden and everything else is
>>>>> publicity. - Bill Moyers
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------------
>>>>
>>>> The arc of history bends towards justice. - Dr. Martin Luther
>>>> King, Jr.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pd-dev mailing list
>>>> Pd-dev at iem.at
>>>> http://lists.puredata.info/listinfo/pd-dev
>>
>>
>>
>>
>>
>> ----------------------------------------------------------------------------
>>
>> Programs should be written for people to read, and only incidentally
>> for machines to execute.
>> - from Structure and Interpretation of Computer Programs
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
More information about the Pd-dev
mailing list