[PD] implementing tooltips WAS: Pd-extended 0.43 updates: lots of new editing features

[Hans-Christoph Steiner]

On Jul 11, 2011, at 3:15 PM, Martin Peach wrote:

> On 2011-07-11 13:45, Mathieu Bouchard wrote:
>> On Mon, 11 Jul 2011, Martin Peach wrote:
>>> On 2011-07-11 12:06, Jonathan Wilkes wrote:
>>>> But I'm not sure where to store the tooltip string...
>>>
>>> Not sure if that's what you mean, but in max the assist method
>>> receives a number corresponding to the inlet or outlet and returns a
>>> pointer to the appropriate string, so the string is already stored
>>> somewhere in the memory allocated to the object.
>>
>> Not necessarily : the assist-method could be storing the data  
>> anywhere,
>> or generating it on-the-fly from whatever.
>>
>
> OK, but the object is responsible for knowing where it is, not Pd.
> If the string is generated on-the-fly or stored elsewhere the object  
> will have allocated the memory for it.
>
>> In theory, tooltip strings could be stored in something at the
>> class-level instead of the object-level, just like methods called  
>> at the
>> object-level refer to a method-table stored at the class-level.
>>
>
> That is indeed what happens: a shared library has a section for  
> strings (or "data"). Unless it is generating them on-the-fly, each  
> instance of the class will refer to the same location in memory for  
> its strings.

This leads to the question: should tooltip messages be per-instance or  
per-class?  It could easily just be a field with a standard name in  
each object's struct, then it would be a simple per-class  
implementation.  Having an 'assist' method means that the external  
writer can decide whether the string is per-class or per-instance.

>> But Pd doesn't allow extending struct t_class by externals, and it
>> doesn't have a tooltip field (except Günter's tooltip diff included a
>> field for storing a symbol containing the text of the left-inlet's
>> text... and only that).
>>
>
> I don't see a need to extend any structs, Pd just needs to call an  
> object's assist method whenever the mouse is hovering over one of  
> its inlet/outlets, and display the returned string inside a box. If  
> there is no assist method, then Pd would use a default string from  
> its own class, depending on what types were registered to that inlet/ 
> outlet at creation time.


I could see this whole thing happening when the object is drawn to the  
screen.  When an object is drawn, then it would just bind a  
'show_tooltip {accepts float, symbol}' proc to each inlet/outlet's  
rectangle.  Then the tooltip message would only be sent across the pd  
--> pd-gui network socket once, and there wouldn't be a need for  
complicated lookups later to determine which instance to send the  
'assist' message to. This would take more memory, but less CPU, and  
would bother the core 'pd' process less.  Since 'pd-gui' runs in a  
separate process, that would mean offloading most of the work to the  
lower priority 'pd-gui' process.


On Jul 11, 2011, at 2:43 PM, Jonathan Wilkes wrote:
>
> I don't get the idea of having a new method that's supposed to be  
> hidden from the user (but really isn't) for every object that wants  
> tooltips; in some cases it would subtly change the function of the  
> object class, like [bang] and [route].  (Aside from crashing Pd,  
> "dsp" isn't such a big deal because there isn't much of a need for  
> an object that takes a signal AND parses arbitrary selectors, esp.  
> on the same inlet.)  Maybe this wouldn't be a problem if
> [textfile] output lists, and there was a [routelist] in Pd vanilla...

This is an important point that Jonathan brings up: if we add an  
'assist' method, that could mess up anything that ever sent a message  
that started with 'assist'.  One idea to work around this would be to  
have the object just send the info to the GUI when it was drawn, like  
above.  This means the GUI would not need to send a message to 'pd' to  
request the data, it would already be in the GUI.  Then we don't need  
to have a new 'assist' message.

.hc


----------------------------------------------------------------------------

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war on  
terrorism.        - retired U.S. Army general, William Odom