[PD-dev] popup,...

[IOhannes m zmoelnig]

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