[PD-dev] what does x->gl_editor represent?
Hans-Christoph Steiner
hans at at.or.at
Thu Jan 21 05:57:24 CET 2010
Ok, another lead, in g_editor.c, for canvas_vis(x, 0), this gets
triggered:
if (!x->gl_havewindow)
{
/* bug workaround -- a graph in a visible patch gets
"invised"
when the patch is closed, and must lose the editor
here. It's
probably not the natural place to do this. Other
cases like
subpatches fall here too but don'd need the editor
freed, so
we check if it exists. */
if (x->gl_editor)
canvas_destroy_editor(x);
return;
}
A non-vised GOP now will have a x->gl_editor even though it doesn't
have its own window. But if it receives a [vis 0(, then that non-
vised GOP will have its gl_editor deleted. That doesn't seem quite
right, right?
.hc
On Jan 20, 2010, at 11:09 AM, Hans-Christoph Steiner wrote:
>
> 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.
>
>
>
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
More information about the Pd-dev
mailing list