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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
