"Dqkit is like [tclkit] on steroids.  It includes [tcl], [tk],
[metakit], [vfs], [zlib], [tclx], [itcl], [itk], [iwidgets], [blt],
[tbcload], tcl[sqlite] and [openssl]+[tls]", according to
fan [Bob Techentin].  It also includes [thread]ing.
Created by [Wojciech Kocjan].


 What: dqkit
 Where: http://sf.net/projects/nstclhttpd
        http://www.sf.net/projects/dqsoftware
 Description: A single file executable which implements a
        tcl interpreter and various extensions.  Based on
        tclkit concept, but includes more extensions,
        at the cost of a larger runtime size.
        Currently at version 0.0 .
 Updated: 09/2004
 Contact: See web site

----
[snichols] I recently downloaded the dqkit and dqkitsh executibles for [Windows] from [SourceForge]. I am trying to use the Thread extension and another custom package that works with regular kit files. Where is dqkit looking for packages within a Thread pool? It can not find my packages when I do a package require. It works fine from my compiled Tcl Thread interp, but not dqkit. Is there something I need to do so it knows where to find my custom packages in my [VFS] kit file? Thanks in advance. S Nichols.

[Wojciech Kocjan] I think it doesn't set auto_path correctly. The easiest thing to do is simply send the right auto_path upon creation. This is actually tricky, because doing it at dqkit level would require many changes, but on the other hand doing it by the person using dqkit is just one line. So I chose the one line solution. And the following can also be used in any situation, I can't imagine why a thread would want a different auto_path by default...

 set tid [thread::create]
 thread::send $tid [list set ::auto_path $::auto_path]

[snichols] Thanks. I tried setting the auto_path variable in the worker thread. The worker thread can not find the Tcl package in the starkit VFS. Any ideas? Thanks in advance.
----

Q: are the sources for dqkit available?
A: ''I see them. Look for dqkit-sources-* in the file list [PAK]''
        (on the sf.net web sites).

Q: was blt compiled with [stubs] for this kit?
A: ''No.  BLT is built in to the underlying wish [PAK]''
----
[JMN] 2004-09-30 
I tried building a minimal dqkit on Windows (with & without MinGW) and on [FreeBSD] but both failed with unenlightening error messages. 

tclsh gen/buildkit build -tcl -tk -thread 

e.g on windows NT:

 [ 3/11] tcl
     sh autoconf
 child process exited abnormally
     while executing
 "exec >@file124b340 2>@file124b340 sh autocon
 ...
     (file "gen/buildkit" line 1055)


On FreeBSD it got a little further... died at step 10/11 when trying to link.

Building software is always such a lottery... I don't hold much hope of the situation ever evolving much from the dogs-breakfast it it is today.

I guess [Batteries Included] tclkits are an acknowledgement of the sheer complexity of the task of ongoing provision of buildable sources across multiple platforms..  but for now, I usually have to build from source to use the packages I want on my chosen primary platforms of Windows & FreeBSD. The problem is that as in the case above, there are so many ways for things to go wrong and often very litle chance for a non-c programmer such as myself to diagnose & fix the errors. 

Unfortunately binary packages for FreeBSD are rare; particularly if you're trying to create a multi-platform tclkit with package versions in sync. When you do find binaries, they may not have been built with the options you require - such as the unfortunate 2nd-class citizenship that threaded builds still seems to have in the Tcl world.

If anyone has some links to downloadable binaries of reasonably recent threaded tlkits for Windows & FreeBSD it'd be much appreciated. (even an un-threaded post tcl8.4.4 tclkit where Tk isn't broken on FreeBSD 5.x would be nice) 
----
KPR - 2005.09.22 - I grabbed the [Windows] version of dqkit from [SourceForge].  I was excited about the inclusion of tclX, specifically (don't laugh) the '''[keyed list]''' commands.  However, apon running [Tkcon] with dqkit (dqkit-Win32-i386-all-v0.4.exe) I get "invalid command name 'keylset'".  Any idea why this is?

[TP] Perhaps you need to
 package require Tclx
before using Tclx commands.
----
[PAK] - 2005.10.14 - BLT uses treeview.cur for treeview and hiertable but Windows can't find it in the virtual filesystem.  To avoid errors, force a builtin resize cursor when running on windows:

  package require Tk
  package require BLT
  option add *Hiertable.ResizeCursor size_we 100
  option add *TreeView.ResizeCursor size_we 100
  pack [blt::hiertable .t]

Without the second option add I get the following error message:

  bad cursor spec "@C:/.../dqkit.exe/lib/blt2.4/treeview.cur"

----

See also [Batteries Included], functionality which dqkit provides.
----
[[
[Category Deployment]
| [Category Tclkit]
]]