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

Jonathan Wilkes jancsika at yahoo.com
Sun Jul 17 01:44:40 CEST 2011



--- On Sun, 7/17/11, Hans-Christoph Steiner <hans at at.or.at> wrote:

> From: Hans-Christoph Steiner <hans at at.or.at>
> Subject: Re: [PD] implementing tooltips WAS: Pd-extended 0.43 updates: lots of new editing features
> To: "Jonathan Wilkes" <jancsika at yahoo.com>
> Cc: "Mathieu Bouchard" <matju at artengine.ca>, "pd-list" <pd-list at iem.at>, "Martin Peach" <martin.peach at sympatico.ca>
> Date: Sunday, July 17, 2011, 1:05 AM
> 
> On Jul 16, 2011, at 5:59 PM, Jonathan Wilkes wrote:
> 
> > 
> > 
> > --- On Sat, 7/16/11, Mathieu Bouchard <matju at artengine.ca>
> wrote:
> > 
> >> From: Mathieu Bouchard <matju at artengine.ca>
> >> Subject: Re: [PD] implementing tooltips WAS:
> Pd-extended 0.43 updates: lots of new editing features
> >> To: "Hans-Christoph Steiner" <hans at at.or.at>
> >> Cc: "pd-list" <pd-list at iem.at>,
> "Martin Peach" <martin.peach at sympatico.ca>
> >> Date: Saturday, July 16, 2011, 6:11 PM
> >> On Mon, 11 Jul 2011, Hans-Christoph
> >> Steiner wrote:
> >> 
> >>> This leads to the question: should tooltip
> messages be
> >> per-instance or per-class?  It could easily
> just be a
> >> field with a standard name in each object's
> struct, then it
> >> would be a simple per-class implementation. 
> Having an
> >> 'assist' method means that the external writer can
> decide
> >> whether the string is per-class or per-instance.
> >> 
> >> Yes... whichever is appropriate. But the default
> >> assist-method should be designed so that in most
> cases,
> >> externals don't need to have a custom
> assist-method.
> >> 
> >>>> I don't see a need to extend any structs,
> Pd just
> >> needs to call an object's assist method whenever
> the mouse
> >> is hovering over one of its inlet/outlets,
> >> 
> >> A default assist-method needs to be storing data
> somewhere,
> >> and it cannot automatically pickup inlet names
> from anywhere
> >> in an external's source code. It has to be stored
> in some
> >> data-structures... For example, in both t_class
> and t_inlet
> >> (for nonproxy inlets).
> > 
> > Is it possible in c to parse a help file for "OUTLET_0
> float symbol"?  That's what I'm currently doing (which
> is trivial on the tcl side).
> > 
> > Actually the way I do it, you parse on the fly only
> when the mouse hovers over the xlet (which you could toggle
> with a menu button).
> 
> Parsing text in C is definitely possible, just not
> fun.  Its much easier in Tcl.
> 
> >>> This is an important point that Jonathan
> brings up: if
> >> we add an 'assist' method, that could mess up
> anything that
> >> ever sent a message that started with 'assist'.
> >> 
> >> Then just do it like it is for savefn and
> propertiesfn. You
> >> see, it doesn't have to be something that goes
> through
> >> class_addmethod. The 'assist' symbol issue is not
> an
> >> argument against defining an assist-method because
> it could
> >> be a field named assistfn directly in t_class.
> > 
> > What do I have to do to register a new
> "assistfn"?  I don't really understand that part of the
> source code.
> 
> 
> That would require adding the assistfn to the t_class
> structure.

Well, my current workaround is to create a binding for each xlet that holds "%W %x %y $xlettype $xletno [list $object_name] [list $object_dir] [list $helpname]".  It's a prototype and obviously not very efficient (takes about 4 seconds to create 1000 [route 1 2 3 4 5 6 7 8 9] objects while unpatched pd takes about 3 seconds), but it's the only way I could figure out to get useful tooltips without redesigning the way the gui interacts with pd AND not add anything to t_class.

Actually maybe there's another way: just create 4 bindings-- 2 for <Enter>/<Leave> of tag "outlet" and 2 for tag "inlet"-- and create a canvas method "canvas_inlethover".  Could actually create a binding for the object itself, too: canvas_objhover, which could be used to send "enter" and "leave" messages to a [struct] object for scalars... :)

-Jonathan



> 
> .hc
> 
> ----------------------------------------------------------------------------
> 
> Computer science is no more related to the computer than
> astronomy is related to the telescope.     
> -Edsger Dykstra
> 
> 
> 



More information about the Pd-list mailing list