[PD] tooltip rfc

[Jonathan Wilkes]

----- Original Message -----
> From: Ivica Ico Bukvic <ico at vt.edu>
> To: 'Jonathan Wilkes' <jancsika at yahoo.com>; pd-list at iem.at
> Cc: 
> Sent: Wednesday, February 27, 2013 6:54 PM
> Subject: RE: [PD] tooltip rfc
> 
>>  Just to clarify, I'm proposing to separate them completely.  So there
>>  would be "autotips" in edit-mode that follow the mouse and that 
> the user
>>  can only turn on or off[1].  There would additionally be a "canvas 
> tip"
> which
>>  the user can already write to using the "tip" method (which could 
> be
>>  renamed
>>  if that causes confusion).
> 
> I see.
> 
>> 
>>  As far as the canvas tips, I'm thinking just use the current syntax for
> the
>>  current behavior:
>>  tip 1 foo <-- show "foo" in canvas tip
>>  tip 0 <-- hide canvas tip
> 
> It might be a good idea then to also extend it to reference a specific
> canvas (or level up kind of like window_name and patch_name and likely
> others do), so you could show a tip from a subpatch on the parent patch.
> E.g.
> 
> tip 1 0 foo (0 would refer to this canvas)
> tip 1 2 foo (2 would be two levels above this one)

The level is actually handled elsewhere-- either with kludges using [namecanvas]
and passing arguments, or much more easily using iemguts or [canvasinfo], e.g.:


[tip 1 foo bar(
|
|    [loadbang]
|    |
|    [name(
|    |
|    [canvasinfo 0] <-- change the arg here for level
|    |
[send]


or
[name(
|
[canvasinfo]
|
[; $1 tip 1 foo bar(

or even

[self(
|
[canvasinfo]
|
[list $1, sendwindow tip 1 foo bar(
|
[pointer]

But that last one is really hacky and I might just remove pointers
from [canvasinfo] altogether since they seem to unnecessarily
complicate the code and the interface.


-Jonathan


>