home | tech | misc | code | bookmarks (broken) | contact | README

Tcl/Tk notes


Images get deformed when using the -grayscale option

In code like that:

image create photo -data [$colorimg data -format bmp -grayscale]

You must check if the parameter to the "format" option is right. In my case, I was putting -format bmp when the correct option is -format jpeg.

Some random notes

Why XOTcl needs Tcl sources to compile

When trying to compile the XOTcl extension for Tcl, I saw it looked for the tclConfig.sh file (this file is in lib/. If someone didn't install it in a default directory, it turns to be necessary to pass the path for this directory with the --with-tcl flag when calling the ./configure script). This file has much data, including the original path of the Tcl source code compiled to generate the binary release.

After checking this file, the ./configure script checks a lot of steps, but it can stop complaining that it couldn't find the tclInt.h file in the original source code tree (took from tclConfig.sh)! I wondered why XOTcl would require those files and I got good explanation here:


there is a short answer and a very long answer to your question. XOTcl needs the Tcl-source since it contains several .h files that are not included in typical binary distributions. Such files are tclInt.h or tclCompile.h. The first one is sneeking into more distributions (a student told me that his SuSE distro includes tclInt.h), tclCompile.h was just needed for speed (1.0.2 has a better configure script that checks automatically this file).

The long answer where i am not going into details is, why des XOTcl need tclInt.h. In short, XOTcl needs it because its needs access to internal of several tcl structures that are not public available. Examples are the structures Command, Namespace, Interp. Certainly it will be possible to define access functions to access the relevant info, and we could try to push these into the tcl-source development, but we have not started this effort jet. Just comment out the include statement of tclInt.h, and you will see how many places are involved. We have on our informal todo-list a step where we define access macros fort the relevant infos, but this is currently not top priority. I agree certainly that it would be much nicer to get rid of tclInt.h.