[PD-dev] bind abstraction-canvas to full classname (namecanvas)

[IOhannes m zmoelnig]

Miller Puckette wrote:
> This might be a good thing to add to the properties menu, but some
> mechanism is also needed to do it programmatically.  For example, an
> abstraction might want to name itself and then send messages to inform
> other part of the patch of the name.
> 
> Perhaps this should be part of a larger "declaration" mechanism that
> would also allow patches to specify search paths and other startup
> needs.  ISPW Max had a "declare" object so you could write
> "declare path=lib:../lib" to add to the search path.  Somthing like
> that is also needed in Pd.
> 

hmm, but using an object ([declare]) has the same problems as using 
another object ([namecanvas]).

probably it would be better to really store data (canvasname, 
paths,...,settings) in the "properties" of the canvas, AND make an 
object to talk to this properties.
this could be an object [canvas]
it would have one inlet to send messages like [vis 1( or [name 
$0-canvas( to ourselves (the canvas we are in).
it would have one outlet, so we can get all messages sent to the canvas 
(no matter what its name may be)

the good thing would be, that the object would not hold the data by 
itself (nor give the user the illusion to do so).
so if the canvas would be renamed to "idontplayguitar" (via a message to 
[canvas]) and then you would delete the [canvas] object, the canvas 
would still be called "idontplayguitar" (just like when you are deleting 
  a [send] object, you do not undo all messages already sent through it).

btw, i even think it better to have an inlet (like the one in [canvas] 
to talk to a canvas than a send-name. this would (hopefully) demystify 
much of the magic that is currently done with "dynamic" patching (i put 
the "dynamic" in quotes, since i am talking more about "vis 1" than 
"clear").


what do you think?

mf.as.dr
IOhannes