I want to add a new ItemType to the Canvas widget. The implemenation
will be in C and hopefully be able to work crossplatform.
I checked out the source code of Tk. It seems that this is possible
using "Tk_CreateItemType(typePtr)". The source code recommends to check
out the implemenation of the built-in types on how to create new
ItemType.
Then, I look at "TkCanvLine.c". I copied this file into a new directory
and then changed "line" to "myline" in the new file to see if things
can work. (see the following snippet)
=============================================================
Tk_ItemType tkLineType = {
"myline", /* name */
sizeof(LineItem), /* itemSize */
CreateLine, /* createProc */
configSpecs, /* configSpecs */
=============================================================
However, to compile the file, the following header files are required:
#include "tkInt.h"
#include "tkPort.h"
#include "tkCanvas.h"
I am trying to get the new C file work with ActiveTcl. (1) The
"include" directory of ActiveTcl only provide "tkInt.h". (2)
"tkCancas.h" is simple and can be copied from the source.
(3) My current problem is how to deal with "tkPort.h"? It is not
included in the ActiveTcl distribution and requires quite some other
files in the Tk source.
Can any one kindly give me some suggestions on how to resolve the above
issues?
Thanks a lot!
Best regards,
Jingzhao
...../tk${version}/generic/tkPort.h
and (post install) in :
/usr/include/tkPort.h
if it is still missing look here:
ftp://www.tcl.tk/pub/tcl/nightly-cvs/
get tk-20050913.tar.gz or newer
it contains :
-rw-r--r-- andreask/users 2981 2002-10-19 08:06:50 tk/win/tkWinPort.h
-rw-r--r-- andreask/users 5163 2003-10-19 08:03:46 tk/unix/tkUnixPort.h
-rw-r--r-- andreask/users 733 2004-04-25 08:04:06 tk/generic/tkPort.h
-rw-r--r-- andreask/users 4983 2004-01-13 08:04:36 tk/macosx/tkMacOSXPort.h
uwe
The internal headers are not available in ActiveTcl, as far as I know.
You need a source build of Tcl and Tk installed on your system to
compile the item type. Then compile with -I/path/to/tk/generic.
Eckhard
By utiIizing the Tcl/Tk source, I am now able to create a DLL. When
loading the DLL into "wish" using "load tkCanvMyLine.dll MyLine", the
canvas will have a new item type. No hack of the Tcl or Tk source code
is required!
It is so cool!
Best regards,
Jingzhao
> However, to compile the file, the following header files are required:
>
> #include "tkInt.h"
> #include "tkPort.h"
> #include "tkCanvas.h"
For your own canvas item type you don't need the internal headers.
They are mostly used for some internal procedures that some Tk types
share, such as TkStateParseProc.
I've written my own canvas item type using just the public headers. The
only problem I've run into is a documentation bug (which I reported).
Make sure you do something like this:
/* should be 0 or 1 */
->alwaysRedraw = 1 | TK_CONFIG_OBJS
You may note that most Tk_ItemType definitions just use TK_CONFIG_OBJS,
and the comments actually say "flags," but the actual structure member
is ->alwaysRedraw.
Another thing I found undocumented was that Tk_ConfigureWidget needs
TK_CONFIG_OBJS.
if (TCL_OK != Tk_ConfigureWidget (interp, Tk_CanvasTkwin (canvas),
tg_config_spec, objc, (CONST char **) objv, (char *)inst,
TK_CONFIG_OBJS)) {
return TCL_ERROR;
}
Unfortunately this is somewhat hackish, because not all pointers are
guaranteed to fit into (char *), but it's what Tk does. Eventually we
may have to cleanup bits like this in Tcl/Tk. There is also a newer API
than Tk_ConfigureWidget that uses a Tk_OptionTable, but the canvas code
hasn't been modified to use that AFAIK.
Have fun,
George
I have checked out the code more carefully. You are right. I just need
the public header to my purpose, which is a great news for my case.
Thanks a lot for your detailed information. It is very helpful!
Best regards,
Jingzhao
Your original message said "hopefully be able to work crossplatform". I
suppose unix would need a .so instead of a .dll, but what would be the
right way to distribute them so it "just worked" on both platforms?
Could you make it a package that loaded the appropriate library?
(This is, of course, a question for the group in general, not you
specifically.)
Thanks for posting this. It is, as you say, "so cool!".
Although there is no such thing as a cross-platform DLL (it's inherently
coupled to some small number of platforms, typically just one) there is
a Tcl-oriented distribution technology that handles this. By packaging
your DLLs for all your various platforms inside a suitable Starkit, you
end up with a file containing platform-specific code that can be loaded
on many different platforms. This is very cool.
The only (minor) downside is that you need to have a Tcl interpreter
that has starkit support available. Of course, this happens to be true
of both tclkit and the recent activetcl distros... ;-)
Donal (there's more to this story, but someone else can tell it)
is it possible to add new canvas itemhandlers in a dynamic way?
if yes would this be wrapable in critcl?
uwe
Depends on what you mean. There's no built-in callback at the moment
when an item create fails because of the item type being unknown, and
although item types can be loaded dynamically, they can't be unloaded at
the moment.
> if yes would this be wrapable in critcl?
Don't know, but probably. ;-)
Donal.
I've delivered a couple of projects as Starpacks, because they are even
simpler for the user if you are supporting only one platform. I've
often wondered how I'd support multiple platforms, if it ever came to
that. I assume I'd deliver a Starkit plus a collection of Tclkits, with
an installer that picked the right one for the platform. Or could I
just install *all* the Tclkits on all the platforms, and launching the
Starkit would just automagically launch the right Tclkit?
place all binary stuff into a system dependent directory
in your app.vfs and load the right ones depending on the
OS at runtime. You can use tcl_platform for the decision.
your delivery then consists of a Starkit for all platforms,
provided you customer has the right Tclkit already installed.
Best regards
Ulrich
In article <2RcYe.1$k6...@dfw-service2.ext.ray.com>,