----- Original Message ----- > From: IOhannes m zmoelnig <zmoel...@iem.at> > To: pd-dev@iem.at > Cc: > Sent: Monday, December 3, 2012 12:13 PM > Subject: Re: [PD-dev] adding a built-in [change] object to the built-in GUI > objects > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2012-12-03 18:10, Jonathan Wilkes wrote: >> >> It'd be even better to use a modern GUI toolkit that has simple >> tools to implement bleeding edge UX technology from the past 15 >> years. Stuff like hyperlinks. :) > > > if hyperlinks is the criterion, then i don't see any problems with tcl/tk.
It's not a binary matter. It's a question of whether I can describe a hyperlink with the tools that tcl/tk provides and not have to spend the same amount of time as I would in c to implement them. Specifically-- tags in a tk canvas are per item while its the opposite in tk text widget. This isn't a difference between defaults for widgets, but incompatibility between them. It means in a canvas you can't easily set Enter/Leave events for a region made up of multiple polygons (which would require unmaintained tkzinc library), and alternately you can't easily define hyperlink Enter/Leave bindings in a text widget without ending up with accidental contiguous tag regions (two hyperlinks in a row, or one hyperlink above another on the next line). Wrt to the Browser2.0 plugin, the straightforward workaround of a proc that defines a new tag name for each hyperlink would probably end up having performance issues since that could potentially be 1000s of unique tags per search. My specific workaround isn't pretty and I can improve it some, but it's still going to suffer from this problem. -Jonathan > > > fgasdmr > IOhannes > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlC83a4ACgkQkX2Xpv6ydvRrYwCg4GEd95Nns/+NYfxLTBwLL02y > VckAoNH7DA9MPFwGcpfGYAXNohrI7Q8k > =0weM > -----END PGP SIGNATURE----- > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev > _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev