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