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
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
