2011/7/12 Hans-Christoph Steiner <h...@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 <h...@at.or.at>wrote: > >> >> On Jul 11, 2011, at 5:35 PM, Jonathan Wilkes wrote: >> >> >>> >>> --- On Mon, 7/11/11, Hans-Christoph Steiner <h...@at.or.at> wrote: >>> >>> From: Hans-Christoph Steiner <h...@at.or.at> >>>> Subject: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots >>>> of new editing features >>>> To: "Jonathan Wilkes" <jancs...@yahoo.com> >>>> Cc: "Martin Peach" <martin.pe...@sympatico.ca>, "Mathieu Bouchard" < >>>> ma...@artengine.ca>, "pd-list" <pd-list@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 <ma...@artengine.ca> >>>>> >>>> wrote: >>>> >>>>> >>>>> From: Mathieu Bouchard <ma...@artengine.ca> >>>>>> Subject: Re: [PD] Pd-extended 0.43 updates: lots >>>>>> >>>>> of new editing features >>>> >>>>> To: "Martin Peach" <martin.pe...@sympatico.ca> >>>>>> Cc: "pd-list" <pd-list@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
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list