SVG-like rendering for the canvas
Tkpath implements path drawing modeled after SVG. It is very flexible and reproduces all standard drawing canvas items. Features include: opacity, antialiasing, gradient fills, affine transformations, and fill rules. Backends include: CoreGraphics on MacOSX, GDI on Win32, GDI+ on WinXP, Cairo on X11, and Tk drawing as a fallback. Not all backends support all features.
Tkpath 0.3.0 provides a new canvas widget that is supposed to be 100% compatible with tk::canvas. My major motivation for creating this package was to make something that maps well with SVG graphics.
Tkpath adds mainly two things:
The new items are:
Most of them can be configured using styles. Instead of setting similar options for each of them, it is possible to create a style, and then use this style for each similar item. When a style is configured, each item using it will be redisplayed.
Using the group item you create a "directory" in the item hierarchy which acts similar to a frame in the widget hierarchy except that options set to the group may be inherited by child items.
The only documentation currently is README.txt , which is very sparse.
Perhaps the easiest way to describe it is to look at these screen shots . Look at the tkpath links.
Note that previous tkpath releases used the tk::canvas item type plugin model for the new item types. This is no longer possible.
Download: just do a cvs checkout and build yourself, or just use the pre-built binaries found in the cvs tree. The only non-standard dependency is on cairo-graphics which is getting common in later linux distros.
The current maintainer of the project seems to be Andrew Shadura. (The original developer, Mats Bengtsson passed away in 2008.) Andrew's repo is available here .
RZ As of 2015-07-03 one can choose from 3 sources:
What is the state of these repositories? It seems all of them are under development.
I tried at first the sources from Andrew's repository. I changed the 'canvas' command to 'tkp::canvas' and removed the '-angle' option from text entries. Then my drawing application started. The only visible difference was the much smaller text strings. I will try it some more.
I got no reply under Ask and it shall be given so try again.
2013-04-13: I'm trying to install tkpath on Windows XP - I have tcl8.6 installed and works. The instructions say 'download from cvs and install'. I downloaded the binaries from cvs, I put it in /tcl and it is not accessible. The demos don't work. The code doesn't work. How did other users install it? When I know I will update the instructions to be useful.
ekd123 tkpath has been in TEApot IIRC.
yyamasak 2012-06-05: I tried 0.3.1 using an analog clock sample (tkpath - clock). I had to redraw clock hands explicitly by calling "event generate .uhr <Configure>". It seems "coord" canvas subcommand does not perform redrawing.
andras 2014-07-31: If you are looking for advanced examples, some current users of TkPath:
escargo 2014-08-01: The README file provided by the github link for Jonas Ferry's TclRobots project above refers to tclrobots.org, which no longerseems to be available. I did find a copy in the Internet Archive: https://web.archive.org/web/20140104074744/http://tclrobots.org/
I couldn't tell what else in the REAMDE might be out of date.
petersteier - 2015-09-09 14:45:34
I tried out to install the package under Ubuntu Server 14.04 LTS (Tcl patchlevel 8.6.1, with apt-get install tcl-dev, tk-dev, libcairo2-dev); a version that worked is from L2Ork's PD project (see above): [L2 ], look in sub-directory pd. It displays the version number 0.3.3. I did not try the repos mentioned here (but was distracted by lots of other wrong information on the web). With ActiveTcl 8.6.1 teacup install does not find tkpath, teacup get downloads several versions, none of which can be installed. Either the config-pathes are wrong, the libcairo2 is incompatible during compiling, or precompiled ELFs are for 32 bit. Also the "original(?)" http://sourceforge.net/projects/tclbitprint/files/ does not work.
arjen's ven.tcl example looks very nice (and antialiased), however, tkpath-clock looks unchanged, even if the "widget" in the source file is changed to "tkp::widget". Is this behaviour correct? Sould the indexes no be antialiased?