--- On Sun, 7/17/11, Hans-Christoph Steiner <[email protected]> wrote:
> From: Hans-Christoph Steiner <[email protected]> > Subject: Re: [PD] implementing tooltips WAS: Pd-extended 0.43 updates: lots > of new editing features > To: "Jonathan Wilkes" <[email protected]> > Cc: "Mathieu Bouchard" <[email protected]>, "pd-list" <[email protected]>, > "Martin Peach" <[email protected]> > 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 <[email protected]> > wrote: > > > >> From: Mathieu Bouchard <[email protected]> > >> Subject: Re: [PD] implementing tooltips WAS: > Pd-extended 0.43 updates: lots of new editing features > >> To: "Hans-Christoph Steiner" <[email protected]> > >> Cc: "pd-list" <[email protected]>, > "Martin Peach" <[email protected]> > >> 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 > > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
