hi ben, hi list
i just checked your [popup], like it and have submitted several (imo) improvements to the CVS. namely: - no restriction for max# of "options"; this might be not very interesting (as on my machine i can only display 40 options at one time, so 100 seems to be sufficient anyhow) BUT i added additionally checks whether the max# has been exceeded; this keeps [popup] from segfaulting when you have more than 100 options
- using a mixture of user-defined and default values if you provide less than 5 arguments (i thought that 5 args are a bit much to remember)
- removed the "loadbang"-constraint (you can now add options and select entries before the object has been drawn the 1st time)
since i only tested it on linux, it would be great if somebody could tell me what i've broken...
but i have some questions: - why are there 2 inlets ? i noticed you uncommented the class_addsymbol()-method, so it seems like there is some reason for not using the 1st inlet for both numeric and symbolic selection of elements.
- even more puzzling: why are there 2 outlets ? for clarification, i don't have any problems with separate outlets for typfixed outlets (1 for numeric indices and 1 for symbolic names), but you are using the first outlet for 2 types (float vs. bang) so you somehow need a route to segregate those types. i would've suggested using either 1 outlet (with either ("bang" and "float" and "symbol") or ("bang" and "list")
since now the "loadbang" seems to work, could the "bang" output be removed ? (i find it rather annoying that everytime i switch console (this is: unhide the window), a bang is emitted.
but i guess, this would break a lot of patches....
mfg.as.dr IOhannes
Hi Johannes,
I will not have a chance to look at your changes until I get back from vacation and start getting my new linux machine going.
Comments inline.
IOhannes m zmoelnig wrote:
hi ben, hi list
i just checked your [popup], like it and have submitted several (imo) improvements to the CVS. namely:
- no restriction for max# of "options"; this might be not very
interesting (as on my machine i can only display 40 options at one time, so 100 seems to be sufficient anyhow) BUT i added additionally checks whether the max# has been exceeded; this keeps [popup] from segfaulting when you have more than 100 options
This sounds good to me. Are you doing some dynamic memory allocation to make this work?
- using a mixture of user-defined and default values if you provide less
than 5 arguments (i thought that 5 args are a bit much to remember)
Any type checking to guess what arguments are what? 5 Arguments is indeed a lot. I'm actually hoping that one day PD will have a nice GUI API that includes the iemgui (or something similar) "inspector" window to change properties (like font, bg and fg colour etc..)
- removed the "loadbang"-constraint (you can now add options and select
entries before the object has been drawn the 1st time)
Ah, how did you make this work? When I tried to send a loadbang to set a value it would always segfault. :( I could not figure out why and so added the funny bang thing, yes this is an ugly hack. Thanks a lot for fixing that, indeed beyond my debugging skill!
since i only tested it on linux, it would be great if somebody could tell me what i've broken...
I'll get on it as soon as a can... busy week.
but i have some questions:
- why are there 2 inlets ? i noticed you uncommented the
class_addsymbol()-method, so it seems like there is some reason for not using the 1st inlet for both numeric and symbolic selection of elements.
This is a design idea, the left side is "float" space and the right side is "symbol" space. I thought two inlets made things more visual sense when there are two outlets. So no there is no technical reason here, aesthetic.
- even more puzzling: why are there 2 outlets ?
for clarification, i don't have any problems with separate outlets for typfixed outlets (1 for numeric indices and 1 for symbolic names), but you are using the first outlet for 2 types (float vs. bang) so you somehow need a route to segregate those types. i would've suggested using either 1 outlet (with either ("bang" and "float" and "symbol") or ("bang" and "list")
As said above the bang is a hack and was not part of the original design. I don't want it! So your right that the idea was to have a separate float only and symbol only outlets.
since now the "loadbang" seems to work, could the "bang" output be removed ? (i find it rather annoying that everytime i switch console (this is: unhide the window), a bang is emitted.
yes yes yes, let me test to make sure it works on my machines.
but i guess, this would break a lot of patches....
Hmmmm, maybe not so many. The suggest "route" usage would mean the lack of a bang would be ignored. What would be missing is the signal to set the value in some "loadbang" cases. Now is probably better to change this than later! I think since so few people complained about the load-bang segfault that most people are not using popup with default values.
Thanks for the contributions Johannes! :)
B>
mfg.as.dr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
B. Bogart wrote:
Hi Johannes,
I will not have a chance to look at your changes until I get back from vacation and start getting my new linux machine going.
well, happy holidays then.
so 100 seems to be sufficient anyhow) BUT i added additionally checks whether the max# has been exceeded; this keeps [popup] from segfaulting when you have more than 100 options
This sounds good to me. Are you doing some dynamic memory allocation to make this work?
yep
- using a mixture of user-defined and default values if you provide less
than 5 arguments (i thought that 5 args are a bit much to remember)
Any type checking to guess what arguments are what? 5 Arguments is indeed a lot. I'm actually hoping that one day PD will have a nice GUI API that includes the iemgui (or something similar) "inspector" window to change properties (like font, bg and fg colour etc..)
well not real type-checking; it is just assuming that you are giving the args in the correct order, but you don't have to remember all of them: so if you know what the 1st 2 args are (width height) but you cannot for the sake of yourself remember what comes next, you just give the 2 parameters and they will be used, and the others will get their default values (e.g. you really want a popup that is 300x100 pixes, but you don't know that the 3rd arg must be the color: now you get a 300x100 popup with default color; prior you got an all default popup)
- removed the "loadbang"-constraint (you can now add options and select
entries before the object has been drawn the 1st time)
Ah, how did you make this work? When I tried to send a loadbang to set a value it would always segfault. :( I could not figure out why and so added the funny bang thing, yes this is an ugly hack. Thanks a lot for fixing that, indeed beyond my debugging skill!
i have to admit it didn't segfault for me at all, i just got error messages concering .x45a310, which normally indicates that tcl-commands are sent to invisible gui-objects. at loadbang-time, the widget is not yet visible, but adding options via the "options"-message automatically draws; so the whole point was, that i had to check whether the widget is visible before sending any sys_vgui()-command (this should be done anyhow; probably it would make even more sense, if sys_vgui() could check this itself)
but i have some questions:
- why are there 2 inlets ? i noticed you uncommented the
class_addsymbol()-method, so it seems like there is some reason for not using the 1st inlet for both numeric and symbolic selection of elements.
This is a design idea, the left side is "float" space and the right side is "symbol" space. I thought two inlets made things more visual sense when there are two outlets. So no there is no technical reason here, aesthetic.
well, speaking of aesthetics, i use [popup] with sends/receives in gop-patches. the gop-patch is quite crowded, so i'd like to be able to control one [popup] with one single [send]. (and i don't want to add some administrative objects like [route] to split one incoming message to 2 outlets) using the cool empty-symbol trick for the second inlet does not allow me to send a message to the first inlet that controls the second one.
probably it would be good to get the best of both worlds: allow symbols on the 1st and on the 2nd inlet, with the same functionality.
- even more puzzling: why are there 2 outlets ?
for clarification, i don't have any problems with separate outlets for typfixed outlets (1 for numeric indices and 1 for symbolic names), but you are using the first outlet for 2 types (float vs. bang) so you somehow need a route to segregate those types. i would've suggested using either 1 outlet (with either ("bang" and "float" and "symbol") or ("bang" and "list")
As said above the bang is a hack and was not part of the original design. I don't want it! So your right that the idea was to have a separate float only and symbol only outlets.
yes, your aesthetic approach makes some sense.
since now the "loadbang" seems to work, could the "bang" output be removed ? (i find it rather annoying that everytime i switch console (this is: unhide the window), a bang is emitted.
yes yes yes, let me test to make sure it works on my machines.
fine
but i guess, this would break a lot of patches....
Hmmmm, maybe not so many. The suggest "route" usage would mean the lack of a bang would be ignored. What would be missing is the signal to set the value in some "loadbang" cases. Now is probably better to change this than later!
a good point
I think since so few people complained about the load-bang segfault that most people are not using popup with default values.
well, probably they either used your bang-hack or they didn't get any segfaults (like me).
Thanks for the contributions Johannes! :)
and i added a "disable"-message to disable user-input (but not effecting the control via inlets) and i added a "set"-message that does not output the values. and i fixed a bug that crashed pd when you had a [popup] in a gop-patch, and something was connected to the the popup's inlets (that was hard to discover)
probably more to come ;-)
mfg.adsr. IOhannes
IOhannes/Ben,
it works like a charm here (linux, devel 0.38.4). loadbang an option doesn't segfault pd anymore!
pat
:)
Thanks again Johannes, I'm trying to test the changes on OSX today.
b>
patrick wrote:
IOhannes/Ben,
it works like a charm here (linux, devel 0.38.4). loadbang an option doesn't segfault pd anymore!
pat
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hey Johannes,
I'm looking at popup and it works on OSX without crashes/bugs. Anyone tried compiling on windows?
getbytes and freebytes are my first memory functions in C, thanks for the intro Joahnnes. :)
Good move when dealing with arguments
Yes on linux it did not segfault for me. On OSX it did. The "initizialize" trick works very well. How did you narrow the problem down to that? Obviously my C debugging skills are pretty low.
As for the idea to have the right inlet and outlet get mirroed in the left inlet outlet my only concern is that in order to seperate the float and symbol messages that one would have to use [segregate]. Is there an easy way of doing this that does not depend on zexy?
I think the awkwardness of seperating the outlet messages by type is more of a problem then the benifit of being able to use a single send and receive in a patch to cover all the inlets/outlets. In what case is it needed to select elements by symbol and index?
Could you do something like: (that you clearly don't want!)
[name test, set symbol mysymbol < | [s to-popup]
[r to-popup] | [route set] | | Right Left <- popup inlet
[popup] | | <- both outlets to one receive [s from-popup]
[r from-popup] | [segregate] | | [float] [symbol]
Or are you proposing that a single symbol being send through the left inlet would do the same thing as the symbol in the right inlet? In this case this is totally acceptable and would not break the way the outlets work. If the patch is that crowded you could use the above example to create an abstraction that takes as little space as a single send/receive:
[popup-receive receive-name] | | [popup] | | [popup-send send-name]
Let me know if I have mis-interpreted something, or if you have an idea of how the current behavior could be preserved for outlets while allowing your ideas.
I'm making a proper PDDP help patch for popup now, will be checked in today.
b>
IOhannes m zmoelnig wrote:
B. Bogart wrote:
Hi Johannes,
I will not have a chance to look at your changes until I get back from vacation and start getting my new linux machine going.
well, happy holidays then.
so 100 seems to be sufficient anyhow) BUT i added additionally checks whether the max# has been exceeded; this keeps [popup] from segfaulting when you have more than 100 options
This sounds good to me. Are you doing some dynamic memory allocation to make this work?
yep
- using a mixture of user-defined and default values if you provide less
than 5 arguments (i thought that 5 args are a bit much to remember)
Any type checking to guess what arguments are what? 5 Arguments is indeed a lot. I'm actually hoping that one day PD will have a nice GUI API that includes the iemgui (or something similar) "inspector" window to change properties (like font, bg and fg colour etc..)
well not real type-checking; it is just assuming that you are giving the args in the correct order, but you don't have to remember all of them: so if you know what the 1st 2 args are (width height) but you cannot for the sake of yourself remember what comes next, you just give the 2 parameters and they will be used, and the others will get their default values (e.g. you really want a popup that is 300x100 pixes, but you don't know that the 3rd arg must be the color: now you get a 300x100 popup with default color; prior you got an all default popup)
- removed the "loadbang"-constraint (you can now add options and select
entries before the object has been drawn the 1st time)
Ah, how did you make this work? When I tried to send a loadbang to set a value it would always segfault. :( I could not figure out why and so added the funny bang thing, yes this is an ugly hack. Thanks a lot for fixing that, indeed beyond my debugging skill!
i have to admit it didn't segfault for me at all, i just got error messages concering .x45a310, which normally indicates that tcl-commands are sent to invisible gui-objects. at loadbang-time, the widget is not yet visible, but adding options via the "options"-message automatically draws; so the whole point was, that i had to check whether the widget is visible before sending any sys_vgui()-command (this should be done anyhow; probably it would make even more sense, if sys_vgui() could check this itself)
but i have some questions:
- why are there 2 inlets ? i noticed you uncommented the
class_addsymbol()-method, so it seems like there is some reason for not using the 1st inlet for both numeric and symbolic selection of elements.
This is a design idea, the left side is "float" space and the right side is "symbol" space. I thought two inlets made things more visual sense when there are two outlets. So no there is no technical reason here, aesthetic.
well, speaking of aesthetics, i use [popup] with sends/receives in gop-patches. the gop-patch is quite crowded, so i'd like to be able to control one [popup] with one single [send]. (and i don't want to add some administrative objects like [route] to split one incoming message to 2 outlets) using the cool empty-symbol trick for the second inlet does not allow me to send a message to the first inlet that controls the second one.
probably it would be good to get the best of both worlds: allow symbols on the 1st and on the 2nd inlet, with the same functionality.
- even more puzzling: why are there 2 outlets ?
for clarification, i don't have any problems with separate outlets for typfixed outlets (1 for numeric indices and 1 for symbolic names), but you are using the first outlet for 2 types (float vs. bang) so you somehow need a route to segregate those types. i would've suggested using either 1 outlet (with either ("bang" and "float" and "symbol") or ("bang" and "list")
As said above the bang is a hack and was not part of the original design. I don't want it! So your right that the idea was to have a separate float only and symbol only outlets.
yes, your aesthetic approach makes some sense.
since now the "loadbang" seems to work, could the "bang" output be removed ? (i find it rather annoying that everytime i switch console (this is: unhide the window), a bang is emitted.
yes yes yes, let me test to make sure it works on my machines.
fine
but i guess, this would break a lot of patches....
Hmmmm, maybe not so many. The suggest "route" usage would mean the lack of a bang would be ignored. What would be missing is the signal to set the value in some "loadbang" cases. Now is probably better to change this than later!
a good point
I think since so few people complained about the load-bang segfault that most people are not using popup with default values.
well, probably they either used your bang-hack or they didn't get any segfaults (like me).
Thanks for the contributions Johannes! :)
and i added a "disable"-message to disable user-input (but not effecting the control via inlets) and i added a "set"-message that does not output the values. and i fixed a bug that crashed pd when you had a [popup] in a gop-patch, and something was connected to the the popup's inlets (that was hard to discover)
probably more to come ;-)
mfg.adsr. IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
B. Bogart wrote:
Hey Johannes,
I'm looking at popup and it works on OSX without crashes/bugs. Anyone
great.
Yes on linux it did not segfault for me. On OSX it did. The "initizialize" trick works very well. How did you narrow the problem down to that? Obviously my C debugging skills are pretty low.
well, this comes from my a-priori knowledge that gui-objects that are not actually displayed (e.g. because they are hidden) but are forced to draw throw some warning in pd. after that, it was easy to notice that there were no checks at all, whether pd is actually allowed to draw the widget and to add an apropriate check.
As for the idea to have the right inlet and outlet get mirroed in the left inlet outlet my only concern is that in order to seperate the float and symbol messages that one would have to use [segregate]. Is there an easy way of doing this that does not depend on zexy?
have you had a look at [segregate] in zexy-2.0 ?
[name test, set symbol mysymbol < | [s to-popup]
[r to-popup] | [route set] | | Right Left <- popup inlet
ah, this reminds me of something important (read below)
Or are you proposing that a single symbol being send through the left inlet would do the same thing as the symbol in the right inlet? In this
exactly.
case this is totally acceptable and would not break the way the outlets work. If the patch is that crowded you could use the above example to create an abstraction that takes as little space as a single send/receive:
[popup-receive receive-name] | | [popup] | | [popup-send send-name]
Let me know if I have mis-interpreted something, or if you have an idea of how the current behavior could be preserved for outlets while allowing your ideas.
concerning outlets, i have only aesthetic concerns (so actually nobody needs to care about them) i would prefer to send out a list "index symbol" instead of 2 atoms "index" and "symbol"
so you get [popup] | [unpack 0 s] | |
you can easily mimick this behaviour with the current [popup] and [pack]
[popup ] | | [pack 0 s] |
so this is not a real problem.
as for inlets: i believe pd follows the following paradigm: "left-most inlet is hot, all other inlets are cold". right inlets can be used for storing things in memory ("set" functionality) or change the state or the object (additional parameters). some objects break this paradigm (cannot think of one right now, though) but i think an object should have really good reasons to do so.
so this would be totally legitimate:
| [route set] \ / X / \ [popup]
(although i think that the 2nd inlet should just automatically call the "set"-method, so you don't _need_ to [route] but it is an option)
so i think: 1st inlet: should have methods for "name", "options" et al should have method for "set" (float or symbol) should have method for "float" should have method for "symbol" 2nd inlet: should be passive and have "set"-functionality
outlets: whatever you like
mfg.ads.r IOhannes
-
B. Bogart -
IOhannes m zmoelnig -
patrick