New Canvas
Mats
ANNOUNCE: tkpath 0.3.0
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
(http://www.w3.org/TR/SVG11/).
Tkpath adds mainly two things:
1) A number of new item types with options that map easily to SVG
objects.
2) A display tree hierarchy with some fancy option inheritance.
The new items are:
circle
ellipse
group
path
pimage
pline
polyline
ppolygon
prect
ptext
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
http://tclbitprint.sourceforge.net/tkpath/README.txt which is very
sparse.
Perhaps the easists way to describe it is to look at the screen shots
at http://tclbitprint.sourceforge.net/, 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 (http://sourceforge.net/cvs/?
group_id=84344)
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.
If anyone want to help then focus on documentation, test code, and
bug patches.
Enjoy, Mats (mat...@gmail.com)
Roy Terry
> sparse.
>
> Perhaps the easists way to describe it is to look at the screen shots
>
> 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 (http://sourceforge.net/cvs/?
> group_id=84344)
> 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.
>
> If anyone want to help then focus on documentation, test code, and
> bug patches.
>
Mats,
As always, I am happy to see your xpath work progressing.
Just to be double clear, does your
new canvas widget "100% compatible with tk::canvas" provide all the
standard canvas items such as oval and line, etc? IOW, is the
new widget a drop-in replacement for all code currently using the
standard canvas?
Thanks,
Roy
Mats
> > sparse.
>
> > Perhaps the easists way to describe it is to look at the screen shots
> > athttp://tclbitprint.sourceforge.net/, 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 (http://sourceforge.net/cvs/?
> > group_id=84344)
> > 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.
>
> > If anyone want to help then focus on documentation, test code, and
> > bug patches.
>
> > Enjoy, Mats (mats...@gmail.com)
>
> Mats,
> As always, I am happy to see your xpath work progressing.
>
> Just to be double clear, does your
> new canvas widget "100% compatible with tk::canvas" provide all the
> standard canvas items such as oval and line, etc? IOW, is the
> new widget a drop-in replacement for all code currently using the
> standard canvas?
>
Yes, that's the idea at least, but I haven't adapted all the
tk::canvas
test code although it is in cvs. The only test I've made was to use
tkp::canvas in my coccinella whiteboard (coccinella.im).which uses
most of the item types.
The cause of any incompatibilities comes from the objectification of
all
option parsing, both the canvas widget itself, and all tk::canvas
items.
This had implications deep inside the code which is probably the
reason
no one objectified the canvas before.
The specific tkpath items were already objectified.
Mats
Roy Terry
advantage of all the cool features in your new canvas. What ever the
set of differences, if they description of what changes might be
needed is complete and clearly defined that will be really helpful as
well.
Mats
As I mentioned before, I have mainly tested the backwards
compatibility
via the whiteboard function I have in Coccinella which uses a lot
of canvas code (18791 total) and then excersized it as much as I
could.
Seems OK. The only change is:
canvas -> tkp::canvas
It couldn't get simpler. So everyone, test it!
Mats
USCode
Mats, was there anything in particular that you found that you were able
to improve that could be put into the standard Tk canvas and that still
has a good chance of being implemented and successfully voted on as a
TIP? Maybe some parts of the canvas internals that were antiquated, etc.?
Torsten Berg
> Seems OK. The only change is:
> canvas -> tkp::canvas
> It couldn't get simpler. So everyone, test it!
>
> Mats
I love this one! Great work, Mats. I'm going to test it soon on my
Mac. One technical question. Is tkp::canvas an enhanced canvas code,
or is this written newly from scratch and just happens to be script-
level compatible to the Tk canvas? What about custom canvas items
introduced via Tk_CreateItemType? Will they magically work togehter
with Tkpath?
Torsten
Mats
>
> Great work Mats, thanks!
>
> Mats, was there anything in particular that you found that you were able
> to improve that could be put into the standard Tk canvas and that still
> has a good chance of being implemented and successfully voted on as a
> TIP? Maybe some parts of the canvas internals that were antiquated, etc.?
All the updated and Tcl_Obj'ectified option handling, both the canvas
widget itself
and all items option parsing. But this has consequences since several
internal structs
need to change as well to work with the option handling.
Then I would love to get rid of the emulated X11 code, at least for
the item drawing.
This is needed to improve performance since each item's display
function sets up its
own graphics context.
That's what comes to mind right now.
There is also a TODO: http://tclbitprint.cvs.sourceforge.net/tclbitprint/tkpath/TODO?revision=1.16&view=markup
Mats
Mats
1) -fill for rect and oval defaulted to black where it should be ""
2) segfault for -dash {2 4 6 4}
Code and updated builds found in cvs. Version now 0.3.1 which
corresponds to HEAD after 0.3.0 release.
Mats
Mats
> > Seems OK. The only change is:
> > canvas -> tkp::canvas
> > It couldn't get simpler. So everyone, test it!
>
> > Mats
>
> I love this one! Great work, Mats. I'm going to test it soon on my
> Mac. One technical question. Is tkp::canvas an enhanced canvas code,
> or is this written newly from scratch and just happens to be script-
> level compatible to the Tk canvas? What about custom canvas items
It is mainly enhanced canvas code but with many rewrites.
> introduced via Tk_CreateItemType? Will they magically work togehter
> with Tkpath?
>
No it wont. Too much internals have changed. Instead I have:
void
Tk_CreatePathItemType(
Tk_PathItemType *typePtr) /* Information about item type; storage
must
* be statically allocated (must live
* forever). */
where you can look up Tk_PathItemType in the sources. I don't have a
stub table
so you probably can't link to it anyway. Perhaps someone can assist
here?
Mats
Ian Gay
>
> ANNOUNCE: tkpath 0.3.0
>
tkpath appears to have some kind of a rendering problem, on Linux, with
some versions of cairo. Using cairo 1.2 on OpenSuse 10.3, tkpath
appears to work ok. With cairo 1.4, there are various nasty problems.
You can see an example by running the following script
-------------------------------------------------------------------
package require Tk
package require tkpath
set wh 200
pack [tkp::canvas .c -width $wh -height $wh -bg white]
foreach {x y f} {50 50 red 150 50 blue 50 150 magenta 150 150 cyan} {
.c create circle $x $y -r 40 -fill $f
}
-----------------------------------------------------------------
in the absence of bugs, you see 4 circles; with the bug, 3 are
truncated.
Does anyone see this behaviour with other Linux distributions?
Is anyone running cairo 1.6 on Linux? Does the bug occur?
Ian
*********** To reply by e-mail, make w single in address **************
Philipp Wissneth
> ANNOUNCE: tkpath 0.3.0
>
> 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
> (http://www.w3.org/TR/SVG11/).
>
I'm having trouble with compiling tkpath on my mac: Using a fresh Tcl/Tk
8.5.3 installation (compiled from source, aqua enabled, framework
disabled) i grabbed the current tkpath via cvs and ran 'configure' with
the following options:
./configure --prefix=<installdir>
--disable-threads
--with-tcl=<installdir>/lib
--with-tk=<installdir>/lib
--with-tclinclude=<installdir>/include
--with-tkinclude=<installdir>/include
Where <installdir> is a path in my homedirectory where the Tcl/Tk
installation resides. When running 'make' this gives me the following error:
----------------------------------------------------------------
...
gcc -pipe -DPACKAGE_NAME=\"tkpath\" -DPACKAGE_TARNAME=\"tkpath\"
-DPACKAGE_VERSION=\"0.3.1\" -DPACKAGE_STRING=\"tkpath\ 0.3.1\"
-DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1
-DUSE_PANIC_ON_PHOTO_ALLOC_FAILURE -I. -I"./generic"
-I"/Users/ph/tcltk85/include" -I"/Users/ph/tcltk85/tk8.5.3/generic"
-I"/Users/ph/tcltk85/tk8.5.3/unix" -I"/Users/ph/tcltk85/tk8.5.3/xlib"
-I/Users/ph/tcltk85/tk8.5.3/macosx -Os -Wall -Wno-implicit-int
-fno-common -c `echo ./generic/tkPathUtil.c` -o tkPathUtil.o
make: *** No rule to make target `tkMacOSXPath.o', needed by
`libtkpath0.3.1.dylib'. Stop.
----------------------------------------------------------------
In addition i'm interested in using tkpath on OS X in an X11 environment
instead of aqua. Has anybody tested this configuration?
Best regards
Philipp
PS: In the TODO i read that there is currently no postscript export
available. Is it planned to implement some export functionality in the
near future?
--
Philipp Wissneth
Arndt Roger Schneider
tkMacOSXPath.c to macosx/tkMacOSXPath.c
Your question: Hmmh, yes with cairo 1.2/ tkpath 0.2.4... and tk 8.4 with
64bit on a PowerPC G5. Tkpath 0.3.1: don't plan to try this yet,
there are quiet a series of issues with tk8.5 and tile under X11/Aqua
and I can't afford to send this machine into cyber-coma.
Your PS:
CAIRO! get another cairo backend then export to whatever you
like to. Wouln't be to hard for the tkpath items --not the legacy
stuff,though.
-roger
Philipp Wissneth
I guess you meant 'tkMacOSXPath.o to macosx/tkMacOSXPath.o'. Then it
works. Thanks!
What i've seen by now looks really great!
> Your question: Hmmh, yes with cairo 1.2/ tkpath 0.2.4... and tk 8.4 with
> 64bit on a PowerPC G5. Tkpath 0.3.1: don't plan to try this yet,
> there are quiet a series of issues with tk8.5 and tile under X11/Aqua
> and I can't afford to send this machine into cyber-coma.
Okay, it's not that important as long as there is a supported Aqua
version of Tk in the future ;)
> Your PS:
> CAIRO! get another cairo backend then export to whatever you
> like to. Wouln't be to hard for the tkpath items --not the legacy
> stuff,though.
Thanks. Didn't see.
Philipp
--
Philipp Wissneth
Arndt Roger Schneider
sorry!
> What i've seen by now looks really great!
>
>
>> Your question: Hmmh, yes with cairo 1.2/ tkpath 0.2.4... and tk 8.4 with
>> 64bit on a PowerPC G5. Tkpath 0.3.1: don't plan to try this yet,
>> there are quiet a series of issues with tk8.5 and tile under X11/Aqua
>> and I can't afford to send this machine into cyber-coma.
>
>
> Okay, it's not that important as long as there is a supported Aqua
> version of Tk in the future ;)
>
... which isn't certain!
Tk is a carbon based application under aqua and
apple has axed support for carbon --there will be no further
improvment on carbon.
This means no-64bit Tk Version for Aqua.
Considering, that virtual every new-sold apple
computer is 64bit there isn't much time to get
Tk onto cocoa. To me it seems: the fastest way is
Cairo (that is instead of the xlib emulation).
>> Your PS:
>> CAIRO! get another cairo backend then export to whatever you
>> like to. Wouln't be to hard for the tkpath items --not the legacy
>> stuff,though.
>
>
> Thanks. Didn't see.
>
>
> Philipp
>
>
-roger
Philipp Wissneth
> Philipp Wissneth schrieb:
>> Okay, it's not that important as long as there is a supported Aqua
>> version of Tk in the future ;)
>>
>
> ... which isn't certain!
> Tk is a carbon based application under aqua and
> apple has axed support for carbon --there will be no further
> improvment on carbon.
That was my thougt, too.
Philipp
--
Philipp Wissneth
Mats
I thought that:
if test "${TEA_WINDOWINGSYSTEM}" = "aqua" ; then
TEA_ADD_SOURCES([macosx/tkMacOSXPath.c])
would do it but seems not. Use Xcode instead. I do.
> ----------------------------------------------------------------
>
> In addition i'm interested in using tkpath on OS X in an X11 environment
> instead of aqua. Has anybody tested this configuration?
>
> Best regards
>
> Philipp
>
> PS: In the TODO i read that there is currently no postscript export
> available. Is it planned to implement some export functionality in the
> near future?
>
My plan is to let someone else do it since I don't know postscript
myself.
It probably isn't that much work since the new items are reproductions
of the old ones,
except the 'path' item which is slightly more complex, but is likely
to match
the Postscript drawing model.
The trick is probably to get the hierachies of inheritances right,
but a look at the items Display function should give some hints.
Mats
Torsten Berg
I now tested a few apps where I normally use the canvas widget. They
just look so much better now (MacOS X)! Smooth letters and lines
everywhere. But I had two issues. I sometimes use [$canvas delete all]
to clean the canvas and start from scratch. This will give me the
error "the root item cannot be deleted". While this behaviour is sort
of documented, it breaks canvas compatibility, where you can delete
all items. I understand the new hierachical model with the root item
always being there, so is there a way around this?
I have a lot of items on the canvas with the tag "bead". When I do
[$canvas delete bead], I get the error
malformed bucket chain in Tcl_DeleteHashEntry
Abort trap
It works in the simple case of
% package require tkpath
0.3.1
% tkp::canvas .c
.c
% pack .c
% .c create oval 0 0 10 10 -tags bead
1
% .c delete bead
%
but fails in my app. I wasn't able to construct a simple case, where
it fails.
Torsten
Arndt Roger Schneider
well, tkpath 0.3 is somthing new and thus
quite a bit rough at some places...
For delete all:
tkpCanvas.c
Line:1218 ff.
case CANV_DELETE: {
int i;
for (i = 2; i < objc; i++) {
FOR_EVERY_CANVAS_ITEM_MATCHING(objv[i], &searchPtr, goto done) {
/*
"delete all" has to ignore the root item
identified as "0" Silently ignored!
-roger 07/20/2008
*/
if (itemPtr->id == 0) continue;
/*
* This will also delete all its descendants by
* recursive calls.
*/
ItemDelete(canvasPtr, itemPtr);
}
}
break;
}
malformed bucketchain: try to make a testcase out of it
and send it too Mats! Although I guess it is related to
the current delete operation (which won't be addressed
by the present code --its structural).
Did You fetch the latest tkpath version ? 0.3.1 I think.
-roger
Mats
> Hi Mats,
>
> I now tested a few apps where I normally use the canvas widget. They
> just look so much better now (MacOS X)! Smooth letters and lines
> everywhere. But I had two issues. I sometimes use [$canvas delete all]
> to clean the canvas and start from scratch. This will give me the
> error "the root item cannot be deleted". While this behaviour is sort
> of documented, it breaks canvas compatibility, where you can delete
> all items. I understand the new hierachical model with the root item
> always being there, so is there a way around this?
We, roger and I, have had some discussions on handling the tag "all"
and I think I just ignore the root item when finding all matching
items to tag "all".
>
> I have a lot of items on the canvas with the tag "bead". When I do
> [$canvas delete bead], I get the error
>
> malformed bucket chain in Tcl_DeleteHashEntry
> Abort trap
>
> It works in the simple case of
>
> % package require tkpath
> 0.3.1
> % tkp::canvas .c
> .c
> % pack .c
> % .c create oval 0 0 10 10 -tags bead
> 1
> % .c delete bead
> %
>
> but fails in my app. I wasn't able to construct a simple case, where
> it fails.
>
There is currently an issue when items are deleted where an item
already deleted implictly via a group is tried to be deleted once
more, which obviously fails (crashes). Instead I think I need to
"flatten out" all items before deleting them so this wont happen (?).
Mats
PS: with "flatten out" I mean to make them direct children of the
root.
USCode
Doesn't it seem Postscript doesn't really belong in Tk anyways and
should probably be a separate extension?
Please correct me if I'm wrong here:
- The current Tk implementation is incomplete?
- Postscript itself is considered obsolete? (PDF)
- Postscript is proprietary? (Adobe)
- Of almost no use to Windows users?
IMHO separate extension(s) that support multiple output format(s) would
be a better solution as output formats come and go with the times and
then you end up with a bunch of obsolete code clogging up the Tk code line.
Mats
I think you are right. There is actually no reason why there should be
an extra postscriptProc member in the callback struct when you define
a new item type. You can get all the data that defines an item from
[$w coords $id] and [$w itemconfigure $id]. A better solution would be
to have a standalone package, or packages, for each desired output
format, like postscript, pdf, SVG etc. I can volunteer for a tkp2svg
package since that's the main reason why I'm doing tkpath anyway. A
svg2tkp package is also planned.
Mats
USCode
> I think you are right. There is actually no reason why there should be
> an extra postscriptProc member in the callback struct when you define
> a new item type. You can get all the data that defines an item from
> [$w coords $id] and [$w itemconfigure $id]. A better solution would be
> to have a standalone package, or packages, for each desired output
> format, like postscript, pdf, SVG etc. I can volunteer for a tkp2svg
> package since that's the main reason why I'm doing tkpath anyway. A
> svg2tkp package is also planned.
>
> Mats
Yes! That's exactly what I had in mind, standalone package(s) for each
desired output format. tkp2svg would be great! Then we will need
tkp2pdf, etc.... ;-)
Arndt Roger Schneider
Not quite!
There are already similar packages: trampoline, it
is called with ps and pdf and a second one tcl4pdf.
So what would be needed there is: active development
on those packages to add groups, prect pline, polyline,
ptext and pimage ... and of course fixing the noted
bugs.
-roger
Philipp Wissneth
> Mats wrote:
>> ANNOUNCE: tkpath 0.3.0
>>
>> 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
>> (http://www.w3.org/TR/SVG11/).
>>
>
> I'm having trouble with compiling tkpath on my mac: Using a fresh Tcl/Tk
> 8.5.3 installation (compiled from source, aqua enabled, framework
> disabled) i grabbed the current tkpath via cvs and ran 'configure' with
> the following options:
>
Well, since my little problem with compiling Tkpath under OS X has been
solved i'm curious if anybody was successful in compiling Tkpath under
Windows XP using Cygwin. I'm using a Tcl/Tk installation that has been
built using Cygwin and the CC="-mno-cygwin" environment variable.
Best regards,
Philipp
--
Philipp Wissneth