[PD] implementing tooltips WAS: Pd-extended 0.43 updates: lots of new editing features

[András Murányi]

On Mon, Jul 11, 2011 at 23:50, Hans-Christoph Steiner <hans at at.or.at> wrote:

>
> On Jul 11, 2011, at 5:35 PM, Jonathan Wilkes wrote:
>
>
>>
>> --- On Mon, 7/11/11, Hans-Christoph Steiner <hans at at.or.at> wrote:
>>
>>  From: Hans-Christoph Steiner <hans at at.or.at>
>>> Subject: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots
>>> of new editing features
>>> To: "Jonathan Wilkes" <jancsika at yahoo.com>
>>> Cc: "Martin Peach" <martin.peach at sympatico.ca>, "Mathieu Bouchard" <
>>> matju at artengine.ca>, "pd-list" <pd-list at iem.at>
>>> Date: Monday, July 11, 2011, 11:18 PM
>>>
>>> On Jul 11, 2011, at 3:58 PM, Jonathan Wilkes wrote:
>>>
>>>
>>>>
>>>> --- On Mon, 7/11/11, Mathieu Bouchard <matju at artengine.ca>
>>>>
>>> wrote:
>>>
>>>>
>>>>  From: Mathieu Bouchard <matju at artengine.ca>
>>>>> Subject: Re: [PD] Pd-extended 0.43 updates: lots
>>>>>
>>>> of new editing features
>>>
>>>> To: "Martin Peach" <martin.peach at sympatico.ca>
>>>>> Cc: "pd-list" <pd-list at iem.at>
>>>>> Date: Monday, July 11, 2011, 7:45 PM
>>>>> On Mon, 11 Jul 2011, Martin Peach
>>>>> wrote:
>>>>>
>>>>>> On 2011-07-11 12:06, Jonathan Wilkes wrote:
>>>>>>
>>>>>>> But I'm not sure where to store the
>>>>>>>
>>>>>> tooltip
>>>
>>>> string...
>>>>>
>>>>>>
>>>>>> Not sure if that's what you mean, but in max
>>>>>>
>>>>> the
>>>
>>>> assist method receives a number corresponding to
>>>>>
>>>> the inlet
>>>
>>>> or outlet and returns a pointer to the appropriate
>>>>>
>>>> string,
>>>
>>>> so the string is already stored somewhere in the
>>>>>
>>>> memory
>>>
>>>> allocated to the object.
>>>>>
>>>>> Not necessarily : the assist-method could be
>>>>>
>>>> storing the
>>>
>>>> data anywhere, or generating it on-the-fly from
>>>>>
>>>> whatever.
>>>
>>>>
>>>> Hm...
>>>>
>>>> 1 when creating an xlet for the first time, bind its
>>>>
>>> tag on <Enter> and <Leave> to call
>>> pdtk_tooltips, and send $canvas, $inletno and $object_name
>>> as arguments
>>>
>>>>
>>>> 2 in tcl, search helppath for $object_name-help.pd,
>>>>
>>> then parse it for $inletno (which I added as a pd META tag
>>> for every internal help patch-- plus lots of externals,
>>> too)
>>>
>>>>
>>>> 3 filter the matching line in tcl to display
>>>>
>>> everything after $inletno minus the semicolon. (I.e., "text
>>> 20 20 INLET_0 float symbol bang;" becomes "float symbol
>>> bang")
>>>
>>>>
>>>> 4 create that text on a little tooltip rectangle on
>>>>
>>> $canvas; delete it on <Leave>
>>>
>>>>
>>>> All you add on the pd side is a sys_gui call to create
>>>>
>>> the binding, then handle everything else on the tcl side.
>>>
>>>>
>>>> Does that make sense?  If so, then once someone
>>>>
>>> gets it working (maybe me), you'd not only have tooltips,
>>> but you'd have tooltip content for over 1000 object classes
>>> (minus exceptions like "list split", and variable/rightmost
>>> inlets which I'm not sure how to handle...)
>>>
>>>>
>>>> Also doesn't address tooltips for abstractions.
>>>>
>>>> -Jonathan
>>>>
>>>
>>> I like this idea quite a bit.  If the tooltip info is
>>> stored in a help patch, then we have a single way of
>>> specifying the tooltip info regardless if the object was
>>> written in C, Pd, Lua, etc.  The downside will be a lot
>>> more file parsing on load.  Perhaps we can do some kind
>>> of low priority thread kind of thing in Tcl to do that
>>> loading.
>>>
>>> One detail, instead of searching the path for the help
>>> patch, really we should try to get the full path of the
>>> object in question, then use that to get the help patch...
>>>
>>
>> Ok.
>> Is c_helpname guaranteed to be inside c_externdir?
>>
>
>
> I can't remember ever using c_helpname, so I can't really say.
>
> IMHO, I don't think we should support other ways of specifying the help
> file.  There are very few objects that use it, those are fixed in
> Pd-extended, it'll add a lot to the work of doing this, etc. etc.  So I say
> just take the object name and add the '-help' to it.  That covers 99.5% of
> objects.  Then once its working, it should be possible to go back and add
> hacks to support hacks ;)
>
> .hc
>

Am I getting right, that this logic could be applied to abstraction xlets
too? How cool...
I don't know much about the new help file system, but I know it's well
thought out, so I'm just asking very carefully: could it be it possible to
allow abstractions to contain their own META tags (in case there's no help
file)?  That would make things even easier (+ less files).

Andras
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110712/229cfb7d/attachment-0001.htm>