Ok, I have a plan to revise the tooltips that are in pd-ext 0.43
- put enter/leave logic on the c-side. This is what pd-l2ork does and it results in easier, more predictable mouseover behavior.
- have autotips appear based on mouse position. This is what tooltips do in most other programs (and how it works in Pd-l2ork).
- separate out the "manual" tips that appear in the corner of the canvas. This can be used by tutorials, independent of the autotips, as well as by objects like [pddplink] to show where the link navigates to in a Firefox-style. (These can also appear/disappear regardless of the edit-mode status.)
- add a "INLET_n_DESC" tag in the [pd META] for objects that want a one to two word description of what an object does. That way a tooltip over the middle inlet of [clip] can tell you it expects the "low value", in addition to the fact that it expects a float.
- fix the bug that makes the tooltip font too small on Windows
And a little more complicated:
- Add some kind of standard "assist" or "tip" method which can be called by the tooltip so an object can provide dynamic data about itself or its xlets.
Example:
- User mouses over the right inlet of [float]
- Pd triggers the tooltip function
- The tooltip function checks if that object has an "assist" method, and if it does it calls it.
- The assist method for [float] sees from its args that the right inlet tooltip was triggered, so
it returns the message "42" which is the value stored at the right inlet. 5) Pd calls the tk proc to draw the tip, which could look something like:
Inlet1- stored value (42) - float
Question is: what args should be expected to the "assist" method? Does it just need to know whether the object, inlet, or outlet tooltip was triggered, plus xletno? What's the best way for the "assist" method to return the values? I'm guessing an array of atoms but I'm not sure.
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: "pd-list@iem.at" pd-list@iem.at Cc: Sent: Wednesday, February 27, 2013 3:42 PM Subject: [PD] tooltip rfc
Ok, I have a plan to revise the tooltips that are in pd-ext 0.43
[...]
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: Sent: Wednesday, February 27, 2013 4:46 PM Subject: Re: [PD] cxc library
[...]
tooltips in pd-l2ork already differentiate between the dynamic (floating) ones and static/manual ones that appear in the bottom-left corner. What is not clear whether both of them can coexist (I think currently they cannot).
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).
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
Then external objects that want to show a canvas tip can call pdtk_tip (or whatever it's named) directly for stuff like text appearing on entering the object with the mouse then going away when leaving the object. The only change would be that when the external wants to remove the text it wrote to the tip, I think the canvas tip widget should return to the state the user had it in previously. So if the canvas receives the message "tip 1 Hello world!", and then someone mouses over a pddplink that shows the tip "http://puredata.info", when the mouse leaves the pddplink it should return to "Hello world!". But that's pretty easy to do through.
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)
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Jonathan Wilkes' jancsika@yahoo.com; pd-list@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
-
Ivica Ico Bukvic -
Jonathan Wilkes