----- Original Message ----- > From: Ivica Ico Bukvic <[email protected]> > To: 'Jonathan Wilkes' <[email protected]>; [email protected] > 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 > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
