[PD-dev] what does x->gl_editor represent?

[Hans-Christoph Steiner]

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.