[PD-dev] tooltips idea
hans at at.or.at
Tue Aug 18 00:16:22 CEST 2009
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
> 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.
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
More information about the Pd-dev