On Mar 12, 2012, at 13:00, Mathieu Bouchard <ma...@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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
