Hey all,
I'm almost finished [popup], with a couple bugs and the biggest issue being that I can't figure out how to pass data from the tk widget back to pd.. (telling it what menu item was selected!) in GGEE button.c seems to do the magic here, could someone explain whats really going on?
sprintf(buf,"button%p",x); x->x_sym = gensym(buf); pd_bind(&x->x_obj.ob_pd, x->x_sym);
sys_vgui("proc button_cb%x {} {\n pd [concat button%p b \;]\n }\n",x,x);
I was originally going to get the external to ouput the symbol that is the same as the menu label selected, but recently working a little more with symbols in PD it seems to be quite a anoyance to test if symbols match (I've been using index from zexy) so I'm now thinking the external will just output the index value of the message. I think it would be handy at times to be able to use the output of the popup as a message directly to some other object, without having to test with an array of selects. Anyone have an opinion on the matter?
I'm hoping to get started writing the [text] external soon for nice text editing...
Thanks Ben
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
Hey all,
I'm almost finished [popup], with a couple bugs and the biggest issue being that I can't figure out how to pass data from the tk widget back to pd.. (telling it what menu item was selected!) in GGEE button.c seems to do the magic here, could someone explain whats really going on?
sprintf(buf,"button%p",x); x->x_sym = gensym(buf); pd_bind(&x->x_obj.ob_pd, x->x_sym);
sys_vgui("proc button_cb%x {} {\n pd [concat button%p b \;]\n }\n",x,x);
I was originally going to get the external to ouput the symbol that is the same as the menu label selected, but recently working a little more with symbols in PD it seems to be quite a anoyance to test if symbols match (I've been using index from zexy) so I'm now thinking the external will just output the index value of the message. I think it would be handy at times to be able to use the output of the popup as a message directly to some other object, without having to test with an array of selects. Anyone have an opinion on the matter?
I think this would be nicer. One use, the popup could have, is selection of files to play somehow. Then you w/could store the filenames inside the popup and on selection play a new file. With an index value, you'd need another storage for the filenames, like pool or so.
ciao
Hey Frank,
I did not think of using a popup menu for file selection. (partically because I had in mind to make a version of Yves playlist using a listbox and scrollbar, so I did not think of the possibility of using a popup.) so I suppose a switch to turn on returning symbols or returning index values would be best. That way when using the menu to select things like gem window messages you could use selects and not have to fill an [index] object with symbols.
Is [index] the best way to compare symbols?
Thanks for the feedback.
Ben
Frank Barknecht wrote:
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
Hey all,
I'm almost finished [popup], with a couple bugs and the biggest issue being that I can't figure out how to pass data from the tk widget back to pd.. (telling it what menu item was selected!) in GGEE button.c seems to do the magic here, could someone explain whats really going on?
sprintf(buf,"button%p",x); x->x_sym = gensym(buf); pd_bind(&x->x_obj.ob_pd, x->x_sym);
sys_vgui("proc button_cb%x {} {\n pd [concat button%p b \;]\n }\n",x,x);
I was originally going to get the external to ouput the symbol that is the same as the menu label selected, but recently working a little more with symbols in PD it seems to be quite a anoyance to test if symbols match (I've been using index from zexy) so I'm now thinking the external will just output the index value of the message. I think it would be handy at times to be able to use the output of the popup as a message directly to some other object, without having to test with an array of selects. Anyone have an opinion on the matter?
I think this would be nicer. One use, the popup could have, is selection of files to play somehow. Then you w/could store the filenames inside the popup and on selection play a new file. With an index value, you'd need another storage for the filenames, like pool or so.
ciao
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
I did not think of using a popup menu for file selection. (partically because I had in mind to make a version of Yves playlist using a listbox and scrollbar, so I did not think of the possibility of using a popup.)
Yeah, probably a listbox is a better widget for this. Actually Yves' playlist would be fine, but I think, you can only use it for file system directories, or not? I cannot check currently as the plalist I have here doesn't run on 0.37 yet.
so I suppose a switch to turn on returning symbols or returning index values would be best. That way when using the menu to select things like gem window messages you could use selects and not have to fill an [index] object with symbols.
Maybe use two outlets, one for the stored symbol, on for the numerical index value?
ciao
hi Ben (and Guenter?),
in a short-term project you will probably find yourself on a safer side, since toxy is still very immature.
Taking a longer-term view, however, I do not understand, why should anybody prefer writing and maintaining (esp. through Pd api changes) a few-hundred-or-more-line external, to a few lines of a simple Tcl code, which has to be embedded in that external, anyway.
At least, there are no fundamental stability, nor performance gains I can think of...
Krzysztof
B. Bogart wrote: ...
I'm almost finished [popup], with a couple bugs and the biggest issue being that I can't figure out how to pass data from the tk widget back to pd.. (telling it what menu item was selected!) in GGEE button.c seems to do the magic here, could someone explain whats really going on?
sprintf(buf,"button%p",x); x->x_sym = gensym(buf); pd_bind(&x->x_obj.ob_pd, x->x_sym);
sys_vgui("proc button_cb%x {} {\n pd [concat button%p b \;]\n }\n",x,x);
defines a procedure to be configured into a button's -command. The proc, when invoked, sends a 'b' message to the object.
Hi Krzysztof,
At this point I have been able to get closer to what I need with an external in two days than I have been able to in weeks of toxy tinkering. This is a short term solution at this point, as a deadline is drawing near.
I will continue working with Toxy though, and I reallt think it has great potencial. I do find it a little chalanging to work with toxy, especially lower-level things like the width of the popup widget, the size and shape of the bounding box etc.. Are you working on a language reference for toxy? I found the biggest stumbling having to be always asking you personally what things mean and how to deal with them.
If you end up making a text widget example, that returns a list of text items in the examples I'll be very likely to use that in my project, but I may just be able to make an external with the same functionality in less time.
I really do appreciate your efforts in the development of toxy, and taking the time to answer my questions. Your work is highly appreciated.
Thanks Ben
Krzysztof Czaja wrote:
hi Ben (and Guenter?),
in a short-term project you will probably find yourself on a safer side, since toxy is still very immature.
Taking a longer-term view, however, I do not understand, why should anybody prefer writing and maintaining (esp. through Pd api changes) a few-hundred-or-more-line external, to a few lines of a simple Tcl code, which has to be embedded in that external, anyway.
At least, there are no fundamental stability, nor performance gains I can think of...
Krzysztof
B. Bogart wrote: ...
I'm almost finished [popup], with a couple bugs and the biggest issue being that I can't figure out how to pass data from the tk widget back to pd.. (telling it what menu item was selected!) in GGEE button.c seems to do the magic here, could someone explain whats really going on?
sprintf(buf,"button%p",x); x->x_sym = gensym(buf); pd_bind(&x->x_obj.ob_pd, x->x_sym);
sys_vgui("proc button_cb%x {} {\n pd [concat button%p b \;]\n }\n",x,x);
defines a procedure to be configured into a button's -command. The proc, when invoked, sends a 'b' message to the object.
On Thu, 19 Feb 2004, Krzysztof Czaja wrote:
hi Ben (and Guenter?),
in a short-term project you will probably find yourself on a safer side, since toxy is still very immature.
Taking a longer-term view, however, I do not understand, why should anybody prefer writing and maintaining (esp. through Pd api changes) a few-hundred-or-more-line external, to a few lines of a simple Tcl code, which has to be embedded in that external, anyway.
Well, I can only reiterate that I am not really happy with the approach that I have taken in these externals.
I didn't know about toxy at that time, if I had known, or if toxy already existed, probably I would not have changed them to use native tcl/tk widgets.
Remember, most of the sliders, bangs, toggles etc that are in the iemgui came from my external collection, so the only options I had was making mine different or removing them completely. I made them different in order to test the embedding of standard widgets.
At least, there are no fundamental stability, nor performance gains I can think of...
Absolutely right.
Guenter
Krzysztof
B. Bogart wrote: ...
I'm almost finished [popup], with a couple bugs and the biggest issue being that I can't figure out how to pass data from the tk widget back to pd.. (telling it what menu item was selected!) in GGEE button.c seems to do the magic here, could someone explain whats really going on?
sprintf(buf,"button%p",x); x->x_sym = gensym(buf); pd_bind(&x->x_obj.ob_pd, x->x_sym);
sys_vgui("proc button_cb%x {} {\n pd [concat button%p b \;]\n }\n",x,x);
defines a procedure to be configured into a button's -command. The proc, when invoked, sends a 'b' message to the object.
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
I would be absoluty happy to do everything in toxy, but there are unexpected issues that came out of the toxy development I was unable to solve (for popup box):
* The objects's bounding box changing side willy-nilly and being altogether wrong on load. (I suppose this is a bug, but I can imagine the code to draw the box around an arbitrary widget could be a little complicated.) Actually I would prefer the non-selected bounding box just not be there, the widgets's themselves have sufficient borders. Only the blue on select box should remain, and its size does not need to be perfect.
* The inability to change the width of the "menubutton" widget. I tried with messages inside the patch, and in the .wid file, but the menubutton always apears a fixed size. On OSX it is big enough for maybe 4 chars.
* I could not figure out a good way to set the menu options using a toxy widget. The first solution was to use $ arguments in the abstraction, problem being I had to refer to all of them in the toxy code [list $1 $2 $3 $4 $5 ...]. Also this lead to object boxes many times wider than the widget itself, making it awkward in a gui. I decided to try an external when I was implimenting a message to set the menu options, but how to store these menu items when the patch is saved?
If I saw solutions to these two problems I would be continuing to use toxy. I have a vested interest in toxy being able to do what I am aiming for, and so I think it would be great if (visually) my current popup external could serve as an example.
Guenter, on what user-centered level were you unhappy with your externals? I've been able to use button.c to do what I want withpopup in about 30 or so lines of additions (and two days of effort). Do the iemguis have any changes that make them more acceptable since your initial writing?
After this growing discussion, to bring things back to the thread subject, how can I get my tk widget -command to send data back over to the PD side? (see the original post for code reference) I'd really like to get it to work! pd_bind??
Personally I think the bottom line is that there is interest in more intuitive (and at least for me) more well-integrated looking GUIs. I think standard tk widgets is a great way to do this, along side of a little extra GOP effort. I can post a grab the patch for which this popup menu is for if anyone is interested.
Thanks Ben
guenter geiger wrote:
On Thu, 19 Feb 2004, Krzysztof Czaja wrote:
hi Ben (and Guenter?),
in a short-term project you will probably find yourself on a safer side, since toxy is still very immature.
Taking a longer-term view, however, I do not understand, why should anybody prefer writing and maintaining (esp. through Pd api changes) a few-hundred-or-more-line external, to a few lines of a simple Tcl code, which has to be embedded in that external, anyway.
Well, I can only reiterate that I am not really happy with the approach that I have taken in these externals.
I didn't know about toxy at that time, if I had known, or if toxy already existed, probably I would not have changed them to use native tcl/tk widgets.
Remember, most of the sliders, bangs, toggles etc that are in the iemgui came from my external collection, so the only options I had was making mine different or removing them completely. I made them different in order to test the embedding of standard widgets.
At least, there are no fundamental stability, nor performance gains I can think of...
Absolutely right.
Guenter
Krzysztof
B. Bogart wrote: ...
I'm almost finished [popup], with a couple bugs and the biggest issue being that I can't figure out how to pass data from the tk widget back to pd.. (telling it what menu item was selected!) in GGEE button.c seems to do the magic here, could someone explain whats really going on?
sprintf(buf,"button%p",x); x->x_sym = gensym(buf); pd_bind(&x->x_obj.ob_pd, x->x_sym);
sys_vgui("proc button_cb%x {} {\n pd [concat button%p b \;]\n }\n",x,x);
defines a procedure to be configured into a button's -command. The proc, when invoked, sends a 'b' message to the object.
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
hi Ben,
it is wonderful you have invested so much time, with trust and patience. I feel sorry for not having more time for toxy myself, lately, causing much confusion, as it seems. Using it in a current project is a challenge I would not dare to advertise -- my other remark came out of a general concern about duplicating code, keeping developers in sync, etc.
Now, what bothers me, is the ``bounding box'' phenomenon:
B. Bogart wrote: ...
- The objects's bounding box changing side willy-nilly and being
altogether wrong on load. (I suppose this is a bug, but I can imagine the code to draw the box around an arbitrary widget could be a little complicated.) Actually I would prefer the non-selected bounding box just not be there, the widgets's themselves have sufficient borders. Only the blue on select box should remain, and its size does not need to be perfect.
I have never seen anything like that... perhaps, there is some incompatibility with the cvs branch of Pd? Even stranger is this:
$3 $4 $5 ...]. Also this lead to object boxes many times wider than the widget itself, making it awkward in a gui. I decided to try an external
You mean the text object box is still visible behind the widget? I am lost...
Also, changing menubutton's width is as simple, as sending '-width <nchars>' to its [tow], or including it in the argument list, or declaring in a .wid file -- everything works here, in linux, using Miller's branch (this might be the case of some osx peculiarity I am not aware of, though).
Configuring the menu is simple too, e.g. changing item's text on the fly with "tot .-.pop entryconfig <itemno> -label <newtext>", same with menu subcommands: 'add', 'delete', ...
Krzysztof
On Thu, 19 Feb 2004, B. Bogart wrote:
Guenter, on what user-centered level were you unhappy with your externals? I've been able to use button.c to do what I want withpopup in about 30 or so lines of additions (and two days of effort). Do the iemguis have any changes that make them more acceptable since your initial writing?
Its not about changes, but additions. The preferences settings (e.g the old ggext sliders needed a message "color" to set their color).
On the "user-centered" level I think the widgets are quite ok. They somehow have a faster feel than the vector drawn implementation. They are nicely decoupled from the sound engine, minimizing communication between the GUI and the pd engine.
The implementation is a bit hacky and the tcl/tk part is not sufficiently decoupled from the external (e.g. it is not easy to plug in other toolkits widgets such as QT or wxWindows).
This means before starting to expand the object with functionality this issues would have to be taken into account.
After this growing discussion, to bring things back to the thread subject, how can I get my tk widget -command to send data back over to the PD side? (see the original post for code reference) I'd really like to get it to work! pd_bind??
Yes,basically you bind the object to a symbol, say foo123 and send commands to it from the tcl/tk side (with "pd foo123 what_evermessage"). That is what the callback function in the code does.
Personally I think the bottom line is that there is interest in more intuitive (and at least for me) more well-integrated looking GUIs. I think standard tk widgets is a great way to do this, along side of a little extra GOP effort. I can post a grab the patch for which this popup menu is for if anyone is interested.
If you had the code and a small example (help file). you could check it into the CVS, thats what it is meant for.
Guenter
Thanks Ben
guenter geiger wrote:
On Thu, 19 Feb 2004, Krzysztof Czaja wrote:
hi Ben (and Guenter?),
in a short-term project you will probably find yourself on a safer side, since toxy is still very immature.
Taking a longer-term view, however, I do not understand, why should anybody prefer writing and maintaining (esp. through Pd api changes) a few-hundred-or-more-line external, to a few lines of a simple Tcl code, which has to be embedded in that external, anyway.
Well, I can only reiterate that I am not really happy with the approach that I have taken in these externals.
I didn't know about toxy at that time, if I had known, or if toxy already existed, probably I would not have changed them to use native tcl/tk widgets.
Remember, most of the sliders, bangs, toggles etc that are in the iemgui came from my external collection, so the only options I had was making mine different or removing them completely. I made them different in order to test the embedding of standard widgets.
At least, there are no fundamental stability, nor performance gains I can think of...
Absolutely right.
Guenter
Krzysztof
B. Bogart wrote: ...
I'm almost finished [popup], with a couple bugs and the biggest issue being that I can't figure out how to pass data from the tk widget back to pd.. (telling it what menu item was selected!) in GGEE button.c seems to do the magic here, could someone explain whats really going on?
sprintf(buf,"button%p",x); x->x_sym = gensym(buf); pd_bind(&x->x_obj.ob_pd, x->x_sym);
sys_vgui("proc button_cb%x {} {\n pd [concat button%p b \;]\n }\n",x,x);
defines a procedure to be configured into a button's -command. The proc, when invoked, sends a 'b' message to the object.
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Wed, 18 Feb 2004, B. Bogart wrote:
Hey all,
I'm almost finished [popup], with a couple bugs and the biggest issue being that I can't figure out how to pass data from the tk widget back to pd.. (telling it what menu item was selected!) in GGEE button.c seems to do the magic here, could someone explain whats really going on?
sprintf(buf,"button%p",x); x->x_sym = gensym(buf); pd_bind(&x->x_obj.ob_pd, x->x_sym); sys_vgui("proc button_cb%x {} {\n pd [concat button%p b \\;]\n}\n",x,x);
For the button widget, a callback gets defined (with the sys_vgui() command). This callback is passed as an argument to the widget creation with "button".
This means, everytime the button is pressed, "pd [concat button%p b \;]" is executed, which sends "b" to a receiver symbol.
All a bit complicated :)
Guenter
I was originally going to get the external to ouput the symbol that is the same as the menu label selected, but recently working a little more with symbols in PD it seems to be quite a anoyance to test if symbols match (I've been using index from zexy) so I'm now thinking the external will just output the index value of the message. I think it would be handy at times to be able to use the output of the popup as a message directly to some other object, without having to test with an array of selects. Anyone have an opinion on the matter?
I'm hoping to get started writing the [text] external soon for nice text editing...
Thanks Ben
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-
B. Bogart -
Frank Barknecht -
guenter geiger -
Krzysztof Czaja