On Mon, 22 Oct 2001, Johannes M Zmoelnig wrote:
great, but then we have to tighten somehow (??) pd to the tcl/tk-interface which should not be done (as i understand it). since i am no tcl/tk-hacker i really do not know how this should be done (and therefore it might be quite easily applied, and my thoughts are naught)
The opposite. If there is only one dialog implemented, which understands key/value pairs and handles them, then the array, number boxes dialogs, (which are all separate implementations), could all use this single property settings widget, so could do any gui object ... no piping tcl/tk code from the engine to the gui any more ...
- If, on the other hand, the argument values I see in an object box
are different from those that are in effect because of changing them in some dialog window (and those that I will see after reloading of the patch), then it is going to be a mess I am likely to be completely lost in.
which would be much easier to implement and absolutely nasty (i (speaking for me) would not like this either)
This problem exists already.
- There is a possible change of focus. The purity in Pd promotes
distributed' way of doing things. Simple objects usually require a simple and small set of arguments. I suspect, that the main reason why we need thisargument template dialog', is that we need to pack (too?) many features into one external.yo. as a matter of fact, the programming paradigm of pd is still(?) to see what a patch is doing, by simply looking at it (which btw keeps patches readable, even if you pause using it for some time...)
first time I hear that patches are readable :)
i am still troubled by the iem_gui's (which i use much), because they are so overloaded. pe: who needs an "init"-value if we have (hidden) receive-symbols, so we could initialize these guis from a (separate) init-patch ?
But experiences vary, the 1-3 are only my doubts,
and mine...
I have no strong and clear opinion on that matter.
my (personal) opinion: keep pd pure data
... and the ocean dry :)
No, honestly, I was not proposing to add a feature to pd but to make an existing one more consistent, but as I don't have time to implement it, it's not gonna happen in this case.
Guenter