So I am just adding support to canvas_name and window_name for getting the names from other canvases besides the current one, i.e. parent, toplevel, etc. I am using the now standard numeric notation that is used in [getdir], iemguts, getdollarzero, etc.
What I am wondering is whether it is worth it to add symbol versions of those names too, like "parent" and "toplevel". Or perhaps it would also be useful to be able to stick the name of a canvas there too, like 'pd-mysubpatch' or 'pd-canvas_name-help.pd'. What are people's thoughts on making that part of the standard technique of looking up these kinds of things?
.hc
------------------------------------------------------------------------ ----
If you are not part of the solution, you are part of the problem.
Hans-Christoph Steiner wrote:
So I am just adding support to canvas_name and window_name for getting the names from other canvases besides the current one, i.e. parent, toplevel, etc.
OK.
I am using the now standard numeric notation that is used in [getdir], iemguts, getdollarzero, etc.
Care to give a brief description of that for those that don't know? I'd be interested in adding something similar to pdlua, so that .pd_lua(x) files can access the path(s) of their containing patch(es), would make sense to have the same numbers.
What I am wondering is whether it is worth it to add symbol versions of those names too, like "parent" and "toplevel".
this sounds useful at first, but if it's only two cases then maybe it's not worth the hassle...
Or perhaps it would also be useful to be able to stick the name of a canvas there too, like 'pd-mysubpatch' or 'pd-canvas_name-help.pd'.
Err, why would that be useful if the object is to get the name in the first place (and also, what happens if there are 42 copies of canvas_name-help.pd open...?)
What are people's thoughts on making that part of the standard technique of looking up these kinds of things?
I think often numbers are nicer than names (eg, I'd hate to have to type "greatgreatgreatgrandparent" instead of 5 or whatever it would be).
Claude
On Dec 8, 2008, at 12:21 PM, Claude Heiland-Allen wrote:
Hans-Christoph Steiner wrote:
So I am just adding support to canvas_name and window_name for getting the names from other canvases besides the current one, i.e. parent, toplevel, etc.
OK.
I am using the now standard numeric notation that is used in [getdir], iemguts, getdollarzero, etc.
Care to give a brief description of that for those that don't know? I'd be interested in adding something similar to pdlua, so that .pd_lua(x) files can access the path(s) of their containing patch(es), would make sense to have the same numbers.
0 = current patch 1 = parent 2 = parent's parent etc.
One question I have is about the behavior when you specific more levels than exist. Like [canvas_name 999999]. Should that be an error, warning? Should it give the toplevel? nothing? I am guessing it should give the toplevel, with a warning.
What I am wondering is whether it is worth it to add symbol versions of those names too, like "parent" and "toplevel".
this sounds useful at first, but if it's only two cases then maybe it's not worth the hassle...
Those are the two that will be most commonly used, IMHO, so it could be worth using.
Or perhaps it would also be useful to be able to stick the name of a canvas there too, like 'pd-mysubpatch' or 'pd-canvas_name- help.pd'.
Err, why would that be useful if the object is to get the name in the first place (and also, what happens if there are 42 copies of canvas_name-help.pd open...?)
Currently you get "warning: pd-canvas_name-help.pd: multiply defined" and they all return the first instance of canvas_name-help.pd. That seems appropriate to me.
What are people's thoughts on making that part of the standard technique of looking up these kinds of things?
I think often numbers are nicer than names (eg, I'd hate to have to type "greatgreatgreatgrandparent" instead of 5 or whatever it would be).
Agreed, I think a limited set of names, like "parent", "toplevel" and maybe "current" just to make things explicit. I forgot I had already implemented this, except for the "parent" and "toplevel" part:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/ hcs/canvas_name.c?view=log http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/ hcs/window_name.c?view=log
.hc
Claude
------------------------------------------------------------------------ ----
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hans-Christoph Steiner wrote:
On Dec 8, 2008, at 12:21 PM, Claude Heiland-Allen wrote:
Hans-Christoph Steiner wrote:
So I am just adding support to canvas_name and window_name for getting the names from other canvases besides the current one, i.e. parent, toplevel, etc.
OK.
I am using the now standard numeric notation that is used in [getdir], iemguts, getdollarzero, etc.
Care to give a brief description of that for those that don't know? I'd be interested in adding something similar to pdlua, so that .pd_lua(x) files can access the path(s) of their containing patch(es), would make sense to have the same numbers.
0 = current patch 1 = parent 2 = parent's parent etc.
One question I have is about the behavior when you specific more levels than exist. Like [canvas_name 999999]. Should that be an error, warning? Should it give the toplevel? nothing? I am guessing it should give the toplevel, with a warning.
in iemguts it gives nothing and no warning. however, you get an implicit, programmatic warning: no result from the object means that the specified parent was illegal. it is up to the user to print out an error message.
Agreed, I think a limited set of names, like "parent", "toplevel" and maybe "current" just to make things explicit. I forgot I had already implemented this, except for the "parent" and "toplevel" part:
how's that done in tot? iirc something like "."? which would give us: . .. /
but anyhow, i don't see a real reason for "current" and "parent" (but have no strong opinion about the latter; the former seems much like an overkill to me) the only useful thing i could think of is "toplevel". but then, the concept of "toplevel" is rather alien to me: everything is patches/abstractions. i don't want my patch behave differently just because i have created it as an abstraction within a toplevel patch instead of a toplevel patch itself. this is also the reason why i don't fully understand the concept of [declare] yet (roman probably agrees with me here).
apart from that, i also have an idea to share: how about the possibility to modify the parent-dept via arguments.
something like [canvas_name 2+$1] (definitely not this syntax, it's just to illustrate my idea)
i haven't come up with a real use-case, though...
gfmasdr IOhannes
On Dec 9, 2008, at 3:37 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Dec 8, 2008, at 12:21 PM, Claude Heiland-Allen wrote:
Hans-Christoph Steiner wrote:
So I am just adding support to canvas_name and window_name for getting the names from other canvases besides the current one, i.e. parent, toplevel, etc.
OK.
I am using the now standard numeric notation that is used in [getdir], iemguts, getdollarzero, etc.
Care to give a brief description of that for those that don't know? I'd be interested in adding something similar to pdlua, so that .pd_lua(x) files can access the path(s) of their containing patch(es), would make sense to have the same numbers.
0 = current patch 1 = parent 2 = parent's parent etc. One question I have is about the behavior when you specific more levels than exist. Like [canvas_name 999999]. Should that be an error, warning? Should it give the toplevel? nothing? I am guessing it should give the toplevel, with a warning.
in iemguts it gives nothing and no warning. however, you get an implicit, programmatic warning: no result from the object means that the specified parent was illegal. it is up to the user to print out an error message.
I think it should give a warning since it is similar to asking for a filename that doesn't exist. Or maybe there should be something to represent that it didn't get a result, since it is difficult to test to see that nothing happened in Pd while trivially easy to respond to events. This could be a second status outlet or maybe special keyword.
Agreed, I think a limited set of names, like "parent", "toplevel" and maybe "current" just to make things explicit. I forgot I had already implemented this, except for the "parent" and "toplevel" part:
how's that done in tot? iirc something like "."? which would give us: . .. /
but anyhow, i don't see a real reason for "current" and "parent" (but have no strong opinion about the latter; the former seems much like an overkill to me) the only useful thing i could think of is "toplevel". but then, the concept of "toplevel" is rather alien to me: everything is patches/abstractions. i don't want my patch behave differently just because i have created it as an abstraction within a toplevel patch instead of a toplevel patch itself. this is also the reason why i don't fully understand the concept of [declare] yet (roman probably agrees with me here).
Hmm, that's a good point. Perhaps just the numbers and names are enough.
apart from that, i also have an idea to share: how about the possibility to modify the parent-dept via arguments.
something like [canvas_name 2+$1] (definitely not this syntax, it's just to illustrate my idea)
i haven't come up with a real use-case, though...
I think this is a good idea, but should just use standard Pd syntax, no need for anything special:
[2 ( | [+ $1] | [canvas_name]
.hc
gfmasdr IOhannes
------------------------------------------------------------------------ ----
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
-
Claude Heiland-Allen -
Hans-Christoph Steiner -
IOhannes m zmoelnig