[PD] tooltips in pd-extended 0.43

[Ivica Ico Bukvic]

On Mar 12, 2012, at 13:00, Mathieu Bouchard <matju at artengine.ca> wrote:

> Le 2012-03-06 à 21:04:00, Ivica Ico Bukvic a écrit :
> 
>> I agree, except I don't want to push this notion to the point where unpredictable nature of tcl/tk's canvas implementation entirely hampers or limits tool's productivity and provides a half-baked feature.
> 
> I found Tk to be quite predictable...
> 
>> E.g. it's impossible to highlight nlets or show tooltips when trying to patch a cord because tcl/tk's canvas keeps "current" tag on the object that was last clicked on,
> 
> ... but then I never tried using a tag named "current". Here's a relevant piece of DesireData :

Both of my comments refer to the implementation that is currently in Pd-ext vs. what I have come up with.

Also, what you're suggesting is essentially doubling the work that is already done inside C (again, assuming that one simply applies what you are proposing to the existing C code). C code already has getrect function that takes care of things like fuzzy logic, particularly when trying to connect a cord to an inlet where code already selects nearest inlet (at least it does in pd-l2ork).

I do understand that moving this into tcl/tk domain is ultimately a good thing as it strives toward separation of the GUI from the engine. However, since I am particularly interested in making sure that even interim solutions are as robust and as possible, I decided to alter the system to rely on the C implementation as that has proven to be a more robust (or perhaps I should say more complete and less redundant) approach than the original version.

In addition, and I think I may have already pointed this out earlier, FWIW I am also not convinced that having one system serve both headless runtime mode and network-based GUI editor is a good thing, particularly now that we have libpd. I am much more interested in having direct GUI implementation plus a separate (and if need be GUI-less) runtime client, as dealing with networked GUI has been a huge overhead for the pd-dev community both in terms of implementing new features as well as fixing existing bugs. If one agrees with this approach, then spending time on migrating things into tcl/tk domain may not be the time best spent...

> 
> def Canvas identify_target {x y f} {
>        set c [$self widget]
>        set cx [expr $x*$@zoom]
>        set cy [expr $y*$@zoom]
>        set stack [$c find overlapping [expr $cx-2] [expr $cy-2] [expr $cx+2] [expr $cy+2]]
>        # reversing the stack is necessary for some things
>        # not reversing the stack is also necessary for some other things
>        # we have to figure out something.
>        set stack [lreverse $stack]
>        set target ""
>        foreach tag $stack {set target [$self target $x $y $f $tag]; if {[llength $target] > 1} {break}}
>        if {[llength $target] > 1} {return $target} {return [list "nothing"]}
> }
> 
> def Canvas target {x y f tag} is a much longer method, which looks at tags of a canvas-item to figure out where it comes from.
> 
>> and yet arguably this is where a new user needs tooltips the most. Selection of nlets and their detection is finicky at best, is very unforgiving (you really need to nail that pixel on the screen to get it), and the list goes on.
> 
> In that code, I detect using a square of 5x5 pixels in size, where $cx $cy is the centre of it. This allows fuzzier detection. This is not necessarily the best solution, but that's what we came up with.
> 
> ______________________________________________________________________
> | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC