In the past, I had a project I was developing around TkPath. After the
untimely loss of Mats B., I moved away from TkPath as I assumed the
project would rot from lack of a maintainer.
However, I see it mentioned from time to time here and wonder if someone
else has picked up the project? Looking at its SF CVS repository, it
looks like the latest checkins were nearly a year ago.
So, does anyone have any info on the current and future state of TkPath?
Has someone picked it up, or is everyone just using it in it current
Did I hear "volunteer"?! I've recently taken over as admin the
projects that Mats had, but purely for administrative purposes. I
just added Petasis and Spjuth as members to tkpath to be able to
contribute there, and there are a couple of patches waiting. I do
think tkpath will live on, but it's just recently been revived so you
won't see any activity yet.
You are welcome to be added on as well if you want to assist at any
I've talked with Carlos Tasada (He is listed as a developer of tcbitprint)
in December 2009, tkpath is currently orphand software.
I intend to fork tkpath from tclbitprint, because I am using
tkpath extensivly myself.
Currently, I have a custom 0.2.9 version running on PowerPC G5,
which I want to use as the first forked release.
As for: 0.3.1, the 0.3 version requires considerable more
work than 0.2 --the code is unstable.
Coding on 0.4 will start after the release of tcl/tk 8.6.
The next needed features in 0.4 are clip-path and viewports.
I am also interested in tkpath (to help as much I can), and I am puzzled
by your decision to fork a 0.2.x tkpath. I understand the complexity of
implementing a new canvas widget, but what are the reasons that led Mat
to introduce this support in 0.3.x?
I don't know why he took this decision. But I think there are advantages
to it, for exaple using a gradient as a fill for the canvas backgound
(it cannot currently be done, but it is possible with a custom canvas).
On the other hand, stability fixes may be easy to make, once detected.
We just need more bug reports.
Sorry, my posting wasn't entirely clear.
I do not question Mats implementation of tkpath 0.3
--well Mats and I discussed gradients in 0.3
before it was released by him and I did oppose the
way he wanted to implement gradients in 0.3.
It is easier to improve the 0.2 branch first (bugfixes), with support for
tk 8.4 and 8.5, and after that to stabilize and extend 0.3
--which is what I mean with 0.4-- for tk8.6.
The two dominant features in 0.3 are groups and surface,
the group implementation is what causes the instabillity in 0.3.
SVG is the actual specification for tkpath, the tk canvas plugin
mechanism is insufficient to go any further toward SVG, that
is why Mats started a new canvas implementation --simpler.
tclbitprint and tkpath are unrelated projects,
both are created by Mats Bengtsson.
So, leave the tclbitprint project to tclbitprint and
make a new project for tkpath.
PS: There is a lot more to say about gradients, and your argument
about gradients as the window background is very sound.
I see. To say the truth I also liked better the 0.2.x implementation of
gradients (which could be defined outside of a canvas), than the 0.3.x
approach (the gradients have to be defined inside the canvas widget).
This way the same gradient has to be defined multiple times (one for
each canvas widget that uses it).
I still haven't used groups and surfaces, so I cannot comment on them :-)
The change was necessary for technical reasons: redrawing of
an element with a gradient doesn't work properly within 0.2
> I still haven't used groups and surfaces, so I cannot comment on them :-)
I suspect the creation of surface was related to tclbitprint.
Surface can be utilized to export a (SVG) graphic as an image.
Does this relate to the faulty behaviour of the 0.2.x series shown in
All boxes have the same gradient, but are drawn differently.
Not likely. It's a transient effect, objects ain't automatically
refreshed after changing the
gradient, the Z-order gets disrupted, too.
Show some code pieces.
The screenshot dates back to 2007, no need to see that code any more :-)
I tried to use tkpath back then in a project, but I gave up because of
this bug. But it was at the times tkpath was making its first steps.
I tried again now, and tkpath works for me, apart from some minor
issues, which I fixed in the CVS.
The latest screenshot is here:
(It is the same code as the previous screenshot with minor tweaks to use
a tkpath canvas).