[PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released

[Jonathan Wilkes]

----- Original Message -----

> From: Bill Gribble <grib at billgribble.com>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: Lorenzo Sutton <lorenzofsutton at gmail.com>; "pd-list at iem.at" <pd-list at iem.at>
> Sent: Friday, January 25, 2013 10:05 PM
> Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
> 
>T he case you describe is the easy one, once you introduce any kind of lexical 
> hygiene.  Names in use in a patch bind closely to the patch or scope in which 
> they are used, so there's no danger of escapes from a patch just because its 
> being used within another patch. 

So inside [blah] let's say I have this:

[r foo]
|
[print I_don_t_want_bob_to_trigger_this]

I share my [blah] abstraction with Bob, who creates a [blah] instance in the same
patch where he has

[Click here to start my thing(
|
[s foo]

I suppose I don't know what "lexical hygiene" means.  But I think you have to have
a way to explicitly state that "binding symbol foo applies to >this< canvas and all
of its children, but not to any parents".  Do you have a way to do that without using
the $0 kludge?

There are also use cases for "binding symbol foo applies to all instances of
>this< abstraction", and possibly "all instances of abstractions from >this<
libdir" (though the latter may be overkill).

-Jonathan

> 
> At the same time, references to names that can't be resolved in the local 
> scope do bubble up, so you can have more global names if you need them.
> 
> Thanks,
> Bill Gribble
> 
> On Jan 25, 2013, at 21:27, Jonathan Wilkes <jancsika at yahoo.com> wrote:
> 
>> 
>> 
>> 
>> 
>>  ----- Original Message -----
>>>  From: Bill Gribble <grib at billgribble.com>
>>>  To: Jonathan Wilkes <jancsika at yahoo.com>
>>>  Cc: Lorenzo Sutton <lorenzofsutton at gmail.com>; 
> "pd-list at iem.at" <pd-list at iem.at>
>>>  Sent: Friday, January 25, 2013 7:55 PM
>>>  Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 
> released
>>> 
>>>  On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote:
>>>>>  From: Bill Gribble <grib at billgribble.com>
>>>>>  I am working on a pd-clone intended to explore a lot of the 
> topics in
>>>  this 
>>>>>  thread.  It's not fully baked yet -- the biggest working 
> patch is
>>>  a biquad 
>>>>>  filter designer with pole-zero and freq response plotting -- 
> but
>>>  I'm 
>>>>>  particularly excited about the approach to namespacing and 
> scope
>>>  management, 
>>>>>  which works a lot like hc describes.  Patches have a set of 
> scopes
>>>  which can be 
>>>>>  mapped onto subpatches (represented as layers, not separate 
> windows). 
>>>  Name 
>>>>>  resolution in send/receive elements works like you would want 
> it to.
>>>> 
>>>>  How does scope work for abstractions?
>>> 
>>>  Well, every object in a patch has a name.  To find that object, the 
> tree
>>>  of patches and scopes is crawled upward from the site of the lookup. 
> For
>>>  example, the (equivalent of) [s "foo"] first looks in the 
> scope of the
>>>  [s], then the patch-global scope of the containing patch, then in the
>>>  application global scope for the name "foo". 
>>> 
>>>  Dotted notation can drill down, so [s "foo.bar"] would try to 
> find an
>>>  object named "foo", then find "bar" in its 
> patch-global 
>>>  scope (or an
>>>  object named "bar" within a scope named "foo" in 
> the current 
>>>  patch). 
>>> 
>>>  Does that make sense?
>> 
>>  I don't think I understand it.
>> 
>>  Let's say I have abstraction [blah].  I want [s foo] and [r foo] inside 
> [blah] and
>>  all of [blah]'s children to talk to each other.  Then I want to share 
> my abstraction
>>  with Bob who needn't worry about the send/receive names I used inside 
> [blah]
>>  because they are guaranteed not to conflict with anything he does outside 
> the
>>  scope of the [blah] abstraction (e.g., creating a [s foo] on the same 
> canvas where
>>  a [blah] object sits).
>> 
>>  Can I specify the scope of the s/r symbol in this way?
>> 
>>  Jonathan
>> 
>>> 
>>>  Thanks,
>>>  Bill Gribble  
>>> 
>