[PD-dev] popup,...

[B. Bogart]

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 at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050609/e7bbc109/attachment.pgp>