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

András Murányi muranyia at gmail.com
Tue Jul 12 14:45:21 CEST 2011


2011/7/12 Hans-Christoph Steiner <hans at at.or.at>

>
> On Jul 11, 2011, at 6:09 PM, András Murányi wrote:
>
>
>
> 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).
>
>
> Why not just keep it in the helpfile?  Its super easy to make help files,
> and its a good habit even for your own projects.  If we have to parse both
> abstractions and help files, that means a lot more parsing, making the
> system even slower.
>
> .hc
>
>
As Matju pointed out, abstractions' help file is canvas-help.pd. Other
things to advocate my suggestion:
- Patches themselves are parsed anyway, CPU will only be needed to look up
the META elements.
- The overwhelming majority of abstractions is self-documented at the moment
(also because of the before mentioned canvas-help functionality).
So I could still imagine this logic:
- If the object is an abstraction, its parsed content gets searched for META
elements first.
- If no META stuff found, *maybe* myabstaction-help.pd is checked if exists
(and then parsed etc.).

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


More information about the Pd-list mailing list