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