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

Hans-Christoph Steiner hans at at.or.at
Tue Jul 12 00:35:47 CEST 2011


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


----------------------------------------------------------------------------

There is no way to peace, peace is the way.       -A.J. Muste


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110711/9687f031/attachment-0001.htm>


More information about the Pd-list mailing list