On Aug 17, 2009, at 4:33 PM, Mathieu Bouchard wrote:
On Sun, 16 Aug 2009, Hans-Christoph Steiner wrote:
On Aug 16, 2009, at 10:46 PM, Mathieu Bouchard wrote:
On Sun, 16 Aug 2009, Hans-Christoph Steiner wrote:
So there has been a revived discussion of adding "tooltip" support to inlets/outlets, based on Günter's old patch. I think we should open up the discussion again to see if we can come up with a solution that Miller would accept. I believe his original objection was based on the fact that the patch added a record to the t_class struct. So I was thinking that instead of storing the tooltip data in t_class, it could be stored using a custom struct like t_inletdescription that was then added to object's class.
so the new objection will be based on the fact that the patch added a record to the t_class struct?... i mean, this struct doesn't make any difference with the original objection.
Do you have a record of the original objection? I am just operating on memory.
When I said "original objection", I meant the one you stated above, which may or may not be the same that msp actually said.
I mean that if you add a t_symbol * in the t_class or if you add a t_inletdescription in the t_class or if you add a t_inletdescription
- in the t_class, it's three times the same thing, which is to add a
field in the t_class, which is what msp objected to, therefore your t_inletdescription proposal is not addressing msp's objection.
I had this idea that the tooltips could be added as a function pointer to the class, such that the tooltip value could change according to the object and even according to the moment, instead of being stuck at one value per class; but this idea also doesn't address msp's objection. I say that because you said "that makes sense since every instance should need the same data" and perhaps my first reply about it didn't make you think about what else it could be.
A big problem with the tooltips, is that t_inlets aren't made into classes the same way the t_objects are: most of the time, for a class of t_object, there are no custom t_inlet classes, and instead one of the four basic t_inlet classes are used. It makes the tooltip information shared for the first inlet and non-shared for the rest. this is an irregularity that has to be addressed somehow...
Ok, I miss remembered. It seems the original implementation attached the text to the t_inlet, and t_class was suggested as the preferred struct for that info. It looks like Chris switched the implementation to use t_class.
I started a dev wiki page to keep track of the info, please expand on this. Like was mentioned at PdCon, this could be something like a Python PEP, or feature proposal.
http://puredata.info/dev/InletDescriptions
.hc
----------------------------------------------------------------------------
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler