Hey,
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. Another possibility would be to add it to the t_text/t_object struct which every object has.
I guess the advantage of putting it into t_class is that there would only be one copy of it. That makes sense since every instance should need the same data. Having it elsewhere would mean multiple copies of the same data, AFAICT.
.hc
----------------------------------------------------------------------------
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque
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.
I guess the advantage of putting it into t_class is that there would only be one copy of it.
Indeed.
That makes sense since every instance should need the same data.
Why does this make sense? I mean, how can you actually tell that every instance should need the same data?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
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.
.hc
I guess the advantage of putting it into t_class is that there would only be one copy of it.
Indeed.
That makes sense since every instance should need the same data.
Why does this make sense? I mean, how can you actually tell that every instance should need the same data?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
On Sun, Aug 16, 2009 at 10:58:12PM -0400, 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.
http://sourceforge.net/tracker/?func=detail&aid=1056914&group_id=55736&atid=478072
------------------- http://mccormick.cx
On Mon, 17 Aug 2009, Chris McCormick wrote:
On Sun, Aug 16, 2009 at 10:58:12PM -0400, Hans-Christoph Steiner wrote:
Do you have a record of the original objection? I am just operating on memory.
http://sourceforge.net/tracker/?func=detail&aid=1056914&group_id=55736&atid=478072
Thanks. There is also the word "tooltip" somewhere in:
http://artengine.ca/matju/pd-dev/dataflow-20050318-meeting.irc
but that's only in some talk about the resampling feature of [inlet~]/[outlet~].
This is the only irc meeting log I have that talks about it, and afaict, msp only ever joined #dataflow for those meetings, so all he ever said on irc back then should be there.
The logs of the last meetings aren't there, because i didn't organise them. (actually i had promised to put one of those logs on the web anyway, but someone else did it before i did).
Almost all of the rest of the logs of what he said about pd should be in the pd-list and pd-dev mailing-list archives; however there are some other recordings that I don't have, much of them as audio, from pd conventions, etc., and also some discussions for which there is no recordings, also from the conventions. It's getting hard to put all of that data together and synthesise it. i used to store a lot of the relevant info in my head, but when i realised how little i ought to care about what msp says, compared to how much i did, i started forgetting. that's a good thing.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
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...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
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
On Mon, 17 Aug 2009, Hans-Christoph Steiner wrote:
On Aug 17, 2009, at 4:33 PM, Mathieu Bouchard wrote:
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.
If you read what I wrote at first, you'd realise that the original implementation didn't use only t_inlet, and that Chris didn't change that.
I started a dev wiki page to keep track of the info, please expand on this.
I already expanded on it on the pd-dev mailing-list today. Perhaps it will be read by someone someday... Frankly, if you don't read it on pd-dev, you won't read it on your wiki either.
Like was mentioned at PdCon, this could be something like a Python PEP, or feature proposal.
If the PEP thing was only "mentioned" at PdCon, then it's not gonna happen.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Mon, 17 Aug 2009, Mathieu Bouchard wrote:
If you read what I wrote at first, you'd realise that the original implementation didn't use only t_inlet, and that Chris didn't change that.
I mean I said that the original implementation used both t_class and t_inlet together (it's because of first inlet vs nonfirst inlet). I didn't talk about Chris' changes nor any other changes; but I say it now: nobody ever changed that aspect of the tooltips.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
-
Chris McCormick -
Hans-Christoph Steiner -
Mathieu Bouchard