Hi, everyone,
Is it possible for PD object to generate a pop-up window to input arguments upon it's creation? I just think that having a long list of arguments when instantiating an object is cubersome and less clear. People might not even know that they can have arguments for the object. With pop-up window, it will be a reminder for people to put in arguments. And it will be also more clear to show what the arguments are for.
If anyone has some ideas of how to do that, please help me.
thx
Andy Chen
andychen5018 wrote:
Hi, everyone,
Is it possible for PD object to generate a pop-up window to input arguments upon it's creation? I just think that having a long list of arguments when instantiating an object is cubersome and less clear. People might not even know that they can have arguments for the object. With pop-up window, it will be a reminder for people to put in arguments. And it will be also more clear to show what the arguments are for.
If anyone has some ideas of how to do that, please help me.
thx
Andy Chen
in pd, windows are handled by tcl/tk, and you would have to write tk-code to have pop-up windows. maybe you should look at the g_7_guis.* files
..tcl/tk-code is said to be painful for hackers (but i have never tried myself)
..note, that if you let pop-up a window everytime a certain object is instantiated, you are likely to get into a mess pretty soon (for example, when makeing a patch that contains (say) 20 of your objects, everytime you open this patch, you would have 20 pop-up windows created: myself, i would get completely lost). maybe this should handled rather like the "properties" (which you get on demand only)
..inserting tcl/tk-code into externals would make it even harder than it is now, to (sometimes in the far future) change the pd-gui from tcl/tk to something better....
anyhow, the graphical-objects from the g_7_guis.* (+ pd.tk) will (pretty well ?) describe what you will need....
mfg.cas.sadr IOhannes
On Mon, 15 Oct 2001, IOhannes m zmoelnig wrote:
andychen5018 wrote:
Hi, everyone,
Is it possible for PD object to generate a pop-up window to input arguments upon it's creation? I just think that having a long list of arguments when instantiating an object is cubersome and less clear. People might not even know that they can have arguments for the object. With pop-up window, it will be a reminder for people to put in arguments. And it will be also more clear to show what the arguments are for.
If anyone has some ideas of how to do that, please help me.
thx
Andy Chen
in pd, windows are handled by tcl/tk, and you would have to write tk-code to have pop-up windows. maybe you should look at the g_7_guis.* files
..tcl/tk-code is said to be painful for hackers (but i have never tried myself)
Well, my suggestion to be able to extend user friendliness would be to define a high level propertiy dialog in the tcl/tk code, that would make it possible to use just one function of tcl tk for property input, and it would be easy to port that to other GUI toolkits.
As I see it properties and instantiation arguments are the same, so having one common interface for them would be a good idea.
- its easy to implement
- we would get rid of ugly tcl/tk code piping
- we would have property dialogs for every object that has some states to
be set.
The problems are:
- we have to take care that object that change their number of inlets,
outlets according to some creation argument can do that even after instantiation
Guenter
hi,
this would make quite a radical change in how patches look, and in the way patches are designed, so I think we ought to take into account a few other concerns apart from plain short-term user friendliness. Quick and easy patching is nice, but maintaining large codebase of complex musical pieces is quite a different story. But well, I am not shure, if it is really a proper thing for me to make such comments before Miller speaks...
krzYszcz
guenter geiger wrote: ...
Well, my suggestion to be able to extend user friendliness would be to define a high level propertiy dialog in the tcl/tk code,
...
As I see it properties and instantiation arguments are the same, so having one common interface for them would be a good idea.
...
- we would have property dialogs for every object that has some states to
be set.
...
On Wed, 17 Oct 2001, Krzysztof Czaja wrote:
hi,
this would make quite a radical change in how patches look, and in the way patches are designed, so I think we ought to take into account a few other concerns apart from plain short-term user friendliness. Quick and easy patching is nice, but maintaining large codebase of complex musical pieces is quite a different story. But well, I am not shure, if it is really a proper thing for me to make such comments before Miller speaks...
I don't understand fully why it should change anything except of just having an additional way to input/change arguments for pd objects ?
Guenter
krzYszcz
guenter geiger wrote: ...
Well, my suggestion to be able to extend user friendliness would be to define a high level propertiy dialog in the tcl/tk code,
...
As I see it properties and instantiation arguments are the same, so having one common interface for them would be a good idea.
...
- we would have property dialogs for every object that has some states to
be set.
...
hi,
if we are talking about appearance attributes or some auxiliary parameters (like slider ranges), then there is no disagreement.
But I have some doubts about setting/changing object's behaviour from within properties dialog.
- If the changes are immediately reflected in an object box text,
then there is nothing radical in it, in fact, there is little difference between such a generic dialog and generic `info' message printing object's usage info to the terminal window (my proposal from some time ago).
- 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. Having a floating `inspector' window instead of pop-up properties dialogs would help a little, but not much.
- 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.
But experiences vary, the 1-3 are only my doubts, I have no strong and clear opinion on that matter.
Krzysztof
guenter geiger wrote:
On Wed, 17 Oct 2001, Krzysztof Czaja wrote:
hi,
this would make quite a radical change in how patches look, and in the way patches are designed, so I think we ought to take into account a few other concerns apart from plain short-term user friendliness. Quick and easy patching is nice, but maintaining large codebase of complex musical pieces is quite a different story. But well, I am not shure, if it is really a proper thing for me to make such comments before Miller speaks...
I don't understand fully why it should change anything except of just having an additional way to input/change arguments for pd objects ?
...
very beautiful:
On Mon, 22 Oct 2001, Krzysztof Czaja wrote:
- If the changes are immediately reflected in an object box text,
then there is nothing radical in it, in fact, there is little difference between such a generic dialog and generic `info' message printing object's usage info to the terminal window (my proposal from some time ago).
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)
- 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)
- 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...)
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 ? would it be a very bad idea, to remove such redundant features now (after everybody started to use them) ? i do think so.... this, of course, does not apply to gui-properties like colour,...
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
mfg.cds.sadf IOhannes
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
hi again,
hope it was clear, that I am not against using generic tcl/tk code
to handle all kinds of property dialogs. My question was really:
what are object properties'' andshould we treat them as synonymous
to object creation arguments''. Hope it was clear too, that I do not
know the answer, and my real intention was to provoke some response
from Miller :)
More specific thoughts are below.
guenter geiger wrote: ...
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 ...
Very much true. This would be an ideal solution -- to keep object properties in pd proper in some form of a dictionary, and pass that dictionary to the gui to be handled by a generic dialog.
no piping tcl/tk code from the engine to the gui any more ...
... well, I do not see any such piping in current implementation of graph, array and atom properties dialogs, so maybe it is just a temporary feature of iem objects?
- 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.
...
This problem exists already.
Yes, but maybe we should try to keep it under control?
first time I hear that patches are readable :)
well, those that are unreadable, are unmaintainable :)
Krzysztof
hi,
please forgive me, I must have been blind. It is done exacly in the same way in iem objects as in graph, array and atom, the only difference is, that iem properties are more elaborate, and have some extra labels passed. So there is no tcl/tk piping, anyway, just passing arguments (after packaging them into strings).
Krzysztof
(you all must be sick with my self-replies, sorry again, I will shut up for a while...)
Krzysztof Czaja wrote: ...
... well, I do not see any such piping in current implementation of graph, array and atom properties dialogs, so maybe it is just a temporary feature of iem objects?
-
andychen5018 -
guenter geiger -
IOhannes m zmoelnig -
Johannes M Zmoelnig
-
Krzysztof Czaja