[PD] inlet names (bad?) practice?

[Jonathan Wilkes]

> On Tuesday, March 2, 2021, 1:19:53 PM EST, Claude Heiland-Allen <claude at mathr.co.uk> wrote: 
 > On 02/03/2021 17:45, Jonathan Wilkes via Pd-list wrote:
> > On Tuesday, March 2, 2021, 11:10:36 AM EST, Alexandre Torres Porres 
> <porres at gmail.com> wrote:
>
> > Hi, I was asking people on facebook where did they get the idea of 
> putting names in inlets/outlets, like: [inlet 
> this-inlet-controls-frequency].
>
> Not sure. But A_DEFSYM and A_DEFFLOAT are implemented in a way that 
> allows an arbitrary number of extra float/symbol arguments, so it 
> could be `[inlet this inlet controls frequency]`. Or following the 
> `[get]` and `[set]` pattern-- `[inlet - this inlet controls 
> frequency]` to skip over the first arg that is currently used for 
> up/downsampling.
>
> Someone asked on the Purr Data list about this. It would be easy to 
> implement, but it doesn't cover the case of setting a description for 
> the object itself. Plus I'd much rather just leverage the 
> documentation index in the GUI to look up tooltip data.
>
> -Jonathan
> https://download.puredata.info/dev/InletDescriptions
Yeah, perhaps they got it by somehow discovering that ancient scroll. :)

Anyhow, Albert Graef recently made a nice caching system for the Purr Data doc index. Leveraging that, I *think* I can now add tooltips, completely in the GUI of Purr Data, and only require a single extra string to be sent from the backend on object creation. At that point tooltips would be the cost of essentially looking up a key in JSON, and the cost of the additional DOM element to display it on hover (which would be zero if tooltips are disabled).
-Jonathan
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210302/02164acd/attachment.htm>