Are the questions in the README still valid ?
if yes:
Stick with a generic concept for coordinates -- makes it easier to port
canvas's rect to prect also.
Zinc uses itemconfigure -position to --mostly-- specify coordinates
for some types. As a result zinc does also support coords... duplicated
work.
On tkpath:
I usually create the GUI offscreen, this trriggers some odd
effects in tkpath:
if around ~100 ptext are created wish
crashs with a BUS-Error.
gradients are not properly created --
it does work after a GUI-part was visible.
with tkpath 0.2.2 on OSX-X11(cairo):
Gradients end around 20 pixel left off the right border.
Haven't seen this with 0.1 on aqua.
Are you aware, that linear & radial-gradients are visible
across interpreter bounderies?
I frequently encountered an alloc-trap when using tkpath 0.1 (aqua) and
0.2.2 on X11. This might be related to how you -not-- deal with
interpretes ... I'm not certain about that however -- just guessed it;-(
lineargradient & radialgradient:
The gradient's name is currently tho only way to figure out what
gradient type it is.
I do prefer to specify a gradient-name before the gradient
is created -- there should be a way to ask the gradient which type it is.
Logged In: YES
user_id=108900
Originator: YES
with tkpath 0.2.2 on OSX-X11(cairo):
Gradients end around 20 pixel left off the right border.
Haven't seen this with 0.1 on aqua.
Can't reproduce this on cairo on linux/X11.
lineargradient & radialgradient:
The gradient's name is currently tho only way to figure out what
gradient type it is.
I do prefer to specify a gradient-name before the gradient
is created -- there should be a way to ask the gradient which type it is.
Done.
/Mats