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 :
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