Well, I personally prefer the "status bar" approach than tooltips that nestle up next to my mouse-- that's why I always printed out the tooltip at the bottom of the patch (or at the top if the user is mousing at the bottom). This is basically the Firefox approach seen when you mouse over a link on a web page and a little label appears at the bottom right of the patch (or bottom left, depending on where your mouse is).
However, I think I combined two related features that may not belong together:
- tooltips
- canvas tips
Even though it's not my preference, your tooltip placement seems to work well and is probably the clearest placement for the new user (who will probably benefit most from using them).
No problem, I can make the canvas tips appear at the bottom whereas all others will appear in place. This has been already fixed in the newest version I am currently building (20120305).
Btw-- one thing I notice is that a) I can generate a tip for the object itself while the inlet appears highlighted, and b) once I generate an inlet tip, if I move the mouse horizontally to the right the inlet will continue to be highlighted even though the mouse is no longer over it.
The nlet highlighting is "magnetic" by default to allow for easier patching. I can however see how this could be distracting in terms of object tip "trumping" the nlet tip. Part of this I suspect is toolkit's limitations because tcl/tk's "current" tag inside canvas is rather crude and not necessarily very useful within the context of Pd patching (e.g. when you click on an outlet, "current" tag is stuck to whatever you've clicked even if you are dragging a mouse to another nlet, which means there is no way to highlight nlets when patching).
20120305 version that is currently building now does all the binding logic inside c code and things run a lot smoother.
Cheers!