TkPath maintainer?
Jeff Godfrey
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
state?
Thanks,
Jeff Godfrey
Jeff Hobbs
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
level.
Jeff
Arndt Roger Schneider
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.
-roger
George Petasis
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.
George
Arndt Roger Schneider
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.
-roger
PS: There is a lot more to say about gradients, and your argument
about gradients as the window background is very sound.
Georgios Petasis
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 :-)
George
Arndt Roger Schneider
...and cached...
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 :-)
>
> George
I suspect the creation of surface was related to tclbitprint.
Surface can be utilized to export a (SVG) graphic as an image.
-roger
Georgios Petasis
>> 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).
>
> ...and cached...
>
> The change was necessary for technical reasons: redrawing of
> an element with a gradient doesn't work properly within 0.2
>
Does this relate to the faulty behaviour of the 0.2.x series shown in
this image?
http://www.ellogon.org/~petasis/tcl/Images/WP4Toolkit.png
All boxes have the same gradient, but are drawn differently.
George
Arndt Roger Schneider
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.
-roger
George Petasis
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:
http://www.ellogon.org/~petasis/tcl/TkRibbon/images/EllogonSystem-Gradient.png
(It is the same code as the previous screenshot with minor tweaks to use
a tkpath canvas).
George
Andrew Shadura
I think I'd like to continue the work on tkpath. I see the last commits to the CVS repo were done by Georgios, so I think he'll be interested in participating too.
I've also converted CVS repository to Mercurial, and published it here: https://bitbucket.org/andrew_shadoura/tkpath
So if anyone's interested, welcome to join.
--
WBR, Andrew
Arjen Markus
to compile it (on Windows 7, using MSVC/C++ 10.0) I got messages about a
missing header file "default.h".
It is not in the original SourceForge repository or in the zip-file I retrieved.
Any suggestions? (From the messages that I got after creating a dummy "default.h", I gather it contains the definitions of all manner of default
settings)
Regards,
Arjen
Arjen Markus
includes are files from the Tk source distribution. When I copied these into the
tkpath source tree (they are missing from the Windows distribution, as they are
Tk private header files), I ran into linker problems:
_tkStubsPtr and several others are missing from the libraries.
(Note the leading underscore)
Anyone knows how to deal with that?
Kevin Walzer
consistent with what I encountered when trying to update another of
Mats' packages, tclbitprint: he incorporated a lot of stuff from Tk's
internals in a very fragile way, so that it became impossible to build.
Good luck dealing with this; I eventually gave up and wrote my own print
package.
--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
Arjen Markus
> I'm not sure how to deal with this issue specifically, but it seems
> consistent with what I encountered when trying to update another of
> Mats' packages, tclbitprint: he incorporated a lot of stuff from Tk's
> internals in a very fragile way, so that it became impossible to build.
> Good luck dealing with this; I eventually gave up and wrote my own print
> package.
>
live with the hack of copying them directly from the Tk sources.
BTW rethinking my previous message, I think the leading underscore is not
the problem. It is more probably the _visibility_ of the symbols.
Regards,
Arjen
Donal K. Fellows
like you're building with -DUSE_TK_STUBS and linking against the main Tk
library, which isn't a supported combination. The rule is: if you link
against the stub library, use -DUSE_TK_STUBS, and if you're not linking
against it, don't define that symbol. Pick one.
Donal.
--
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.
Arjen Markus
>
> You shouldn't be referring explicitly to that symbol. In fact, it sounds
> like you're building with -DUSE_TK_STUBS and linking against the main Tk
> library, which isn't a supported combination. The rule is: if you link
> against the stub library, use -DUSE_TK_STUBS, and if you're not linking
> against it, don't define that symbol. Pick one.
>
- I have ActiveTcl 8.6, 64-bits installed and was trying to build the package
with the 32-bits version of the compiler.
- When I finally realised that, I could build a trivial (empty) "package" I had
derived from the Tkpath sources without any problem. Before that I ran
into the same linkage problems.
- Trying to build the Tkpath package with the proper 64-bits compiler failed
however:
- the makefile.vc file refers to a bufferoverflowU.lib in 64-bits mode.
This library does not exist.
- I removed that from the link command and got conflicts on the architecture
(x86 versus IA64 or X64 versus IA64 - depending on whether I had set
the MACHINE environment variable or not)
That is the current status. At least I made some progress :).
George Petasis sent me an alternative version of the makefile.vc file. I will
try that one as well. Keeping you all posted.
Regards,
Arjen
Arjen Markus
I just successfully built Tkpath on Windows 7, using ActiveTcl 8.6 (64-bits)
and MSVC/C++ 10.0.
I had to set the environment variables TCLDIR and MACHINE (the latter to "x64")
and then it all worked smoothly. I used the original makefile.vc with one
adjustment: I removed the bufferoverflowU.lib library.
The demos work jolly nice :).
Regards,
Arjen
swan lee
wich repo did you use to build tkpath? Andrew's one or Sourceforge?
best regards,
Nicolas
Le 10/04/13 12:18, Arjen Markus a �crit :
Arjen Markus
>
> wich repo did you use to build tkpath? Andrew's one or Sourceforge?
>
the possibilities it offers.
Regards,
Arjen
Georgios Petasis
http://www.ellogon.org/~petasis/ellogon/System2.x/ArrowDiagram.png
As the screenshot shows, it supports gradients, rounded rectangles, etc.
George
swan lee
I'm using Tcl/Tk 8.5.14 on MacOSX, the X11 version
and I successfully built tkpath for both 32/64 bits version.
didn't had time to test it yet, but it looks promising...
++
Le 11/04/13 12:06, Arjen Markus a �crit :
avar...@gmail.com
We plan to use tkpath in our software (OMNeT++), and in the last weeks we made several improvements to it:
Bug fixes:
- updated for recent OS X versions (the code did not compile or work
due to the use of deprecated APIs)
- pimage: -width/-height did not work on all platforms
- pimage: faulty rendering of images with partial transparency on Linux
(Cairo requires R,G,B channels to be pre-multiplied by the alpha channel)
- pline, polyline, path: -strokedasharray behavior was inconsistent across
platforms (on Linux, dash lengths were not scaled by the line width)
- transparency was not implemented for gradient fills
- transform skewx/skewy was bogus (needed tan() instead of sin())
- "delete all" was unusable as it always complained about not being able
to delete the root item
New item options:
- pimage: anchoring (-anchor); image interpolation mode (-interpolation);
cropping and tiling (-srcregion); tinting (-tintcolor, -tintamount)
- ptext: anchoring options extended (-textanchor); support for bold
(-fontweight) and italic (-fontslant); contoured text (-filloverstroke)
- pline, polyline, path: arrowhead support (-startarrow, -startarrowlength,
-startarrowwidth, -startarrowfill; same for end arrow)
Other:
- matrix multiplication utility function (tkp::transform mult)
If someone is interested, our repo is here:
https://github.com/omnetpp/tkpath
I already contacted Andrew Shadura who seems to be the current tkpath maintainer, and currently waiting for his reply.
Regards
Andras