[PD-dev] popup,...

IOhannes m zmoelnig zmoelnig at iem.at
Wed Jun 8 18:19:23 CEST 2005


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




More information about the Pd-dev mailing list