On Sat, Feb 10, 2007 at 01:01:48AM +0100, Frank Barknecht wrote:
Matteo Sisti Sette hat gesagt: // Matteo Sisti Sette wrote:
The workaround of creating a subpatch (which you may call $0- or $1-something) is ok if all the dynamically generated stuff is "processing stuff", but what if we are dinamically generating interface elements? It is not irrelevant to have to go one level deeper in the patch tree to get a piece of interface visible. I can think of real-life scenarios...
Well, as I mentioned, this is one usecase for namecanvas, that's not possible with subpatches. But it's a usecase, that not necessarily requires a namepatch-object, it is probably better realized with canvas-Properties similar to graph-on-parent etc.
Not if you want to do it dynamically. For example, I have a couple of abstractions which change their size, depending on the arguments you pass to them. An example is the game-of-life patch I made, which creates toggles dynamically for each cell, and sets the size of the patch to accommodate those toggles. Another example might be an envelope generation patch which the user can specify the resolution of. You might want a physically longer looking envelope abstraction for a longer envelope time.
Or maybe you're talking about something else? The namecanvas issue would be solved if each patch was given a default name like pd-$0 or somesuch.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx