[PD-dev] tooltips idea

[Hans-Christoph Steiner]

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