tcl/tk, itcl, BLT - native X for TkDesk 2.0

[Doug VanLeuven <roamdad at sonic dot net>]

Hi,
I'm an old tkdesk fan.  (shameless plug) I think it's power & flexibility
would be a great addition to the cygwin environment on windows.
I've been using it on cywin/X for over a week now.  It's like coming home
after a long voyage.

I compiled & ran tkdesk with the cygwin tcl/tk, but there are differences
between the X and windows version, some subtle and some not so subtle.
Mostly, the X registry is implemented differently, so a tk app that
depends on defaults in the registry for it's behavior would need to
be redone.

With a tip from http://wiki.tcl.tk/ I compiled tcl/tk, itcl and BLT
as static libs for an undefined unix system.  Tkdesk compiles and runs
with exactly the same look & feel as native Unix.  Even the same bugs.

I'd like to digress here and say the Xlib compatibility, and cygwin
API combo is one of the most amazing feats of compatibility I've
ever witnessed.  I'm still in awe.

I checked back thru 2004 and all I can find are discussions about
previous discussions about an X-based tcl/tk cohabiting the
environment with the cygwin's tcl/tk windows version and not
interfering with insight.

Here's my quandry.  My goal was to get tkdesk 2.0 working well in the
cygwin environment, but that goal now has a certain dependency on
resolving the issues surrounding X-tcl/tk and Win-tcl/tk.

Would it be acceptable to the community to contribute a statically
compiled tkdesk that included everything it needed in it's own directory?
I've been doing this on linux for years now to keep an older version
of tkdesk running using an outdated tcl/tk release.

If not, I never thought of being a maintainer for something like
tcl/tk and friends, and wouldn't even know where to start.
It really is almost trivially easy to compile these apps as
static native X unix apps, but I have no idea what kind of long term
responsibilities that involves or what additional effort will be
required to make dll's.  So I'm not volunteering in this
note.

But if someone was to start maintaining an X tcl/tk, what would be
an acceptable naming convention? Would static be OK?  Is it going
to be sufficient to change paths to find the X version before the
windows version?  Memory usage aside, there are some benefits derived
by not searching for a shared dll.  Is non-interference with insight
the only issue of interaction with an X tcl/tk?

There are a lot of X based tcl/tk applications that could be ported
over without change if the X based tcl/tk existed.  It just seems
a waste to ignore that.

Regards, Doug