shipping tcl/tk apps to users who don't have tcl/tk installed
Chuck Irvine
assume that all potential users will have Tcl and Tk installed. Nor
can I assume that they will install it to run my application. How can
I ship "enough" of tcl/tk for users to be able to run my application?
I do have Ousterhout's book but can't really find an answer to this
question. Help on this issue would be greatly appreciated! Thanks.
PS: Actually, my application uses Tix as well.
--
Chuck Irvine
--------------------------------------------------------------------------
Senior Member of Technical Staff
Systems & Networks, Inc. FAX (913) 841-1345
1310 Wakarusa Dr., Suite A (913) 838-0128
Lawrence, KS 66049 irv...@ks.sysnet.com
Daniel Cade Bigler
Chuck Irvine <irv...@ks.sysnet.com> wrote:
>I have a Tcl/Tk application that I want to distribute, but I can't
>assume that all potential users will have Tcl and Tk installed. Nor
>can I assume that they will install it to run my application.
there are several Tcl/Tk compilers out there... I can't recall any
of the http or ftp addresses right off the top of my head--maybe
someone else can help you with that. I do recall one compiler looking
to be pretty good, but it cost (even with a student discount) $165.
I believe the list price was something like $495! I am interested
in compiling Tcl/Tk executables also, but that's just too much money
for me... Wish ya luck!
Tyson
Ricky L McClanahan
: In article <IRVINE.95...@hopi.ks.sysnet.com>,
: Tyson
You guys can do what I do if you don't mind showing your source
code. I however have access to many different platforms so i
ocmpile tcl and tk on the system I want to target and then I
distribute the wish interpreter created along with a directory
of a few files that tk needs to run. You must also give them a
script that sets the variables TCL_LIBRARY and TK_LIBRARY to this
directory of tcl/tk files.
Here is the script I supplied for one app:
TCL_LIBRARY=/local/user/rick/wish-1/tclstuff
TK_LIBRARY=/local/user/rick/wish-1/tclstuff
#
# SCCS ID: @(#)logon 1.1 95/07/17 17:46:19
#
# setup environment variables before starting wish for the first time.
export TCL_LIBRARY TK_LIBRARY
if [ $# = 0 ]
then
`dirname $TCL_LIBRARY`/wish -f logon.api &
else
`dirname $TCL_LIBRARY`/wish -f "$@" &
fi
---------------------------------------------------
Here is the list of files you need for tk to run:
button.tcl
dialog.tcl
entry.tcl
file
focus.tcl
init.tcl
listbox.tcl
menu.tcl
obsolete.tcl
optionMenu.tcl
parray.tcl
prolog.ps
scale.tcl
scrollbar.tcl
searchbox.tcl
tclIndex
tearoff.tcl
text.tcl
tk.tcl
tkerror.tcl
tkinfo.tcl
topgetopt.tcl
Hope this helps.
John Chambers
>Daniel Cade Bigler (big...@millenium.texas.net) wrote:
>: In article <IRVINE.95...@hopi.ks.sysnet.com>,
>: Chuck Irvine <irv...@ks.sysnet.com> wrote:
>: >I have a Tcl/Tk application that I want to distribute, but I can't
>: >assume that all potential users will have Tcl and Tk installed. Nor
>: >can I assume that they will install it to run my application.
>: [---snipped---]
We had the same problem; it was made worse by the fact that some customers
did have tcl/tk, but an older version than we were using. Our solution has
been to include wish and the tk libraries in our packages. So as not to break
any other applications that need a different release of tk, we simply decree
that our package must be installed in a specific diretory (or you can install
it anywhere, and create a symlink with the required name). Thus, one package
I'm working on has the acronym "NDC". Our scripts all start with "#!/ndc/bin/",
plus the interpreter name. This directory contains versions of wish (and perl)
that were built "knowing" that things are found in /ndc/bin and /ndc/lib,
and it works pretty well.
Of course, this would be rather awkward for just a single, small script. But
if you are dealing with a package with zillions of scripts, or if you make use
of the tcl "source" or perl "require" commands, then it's not much extra work
to include the interpreter as part of the package, and it solves the problem
of having the wrong release in some customer's machine, or of some user not
getting the environment variables ("Huh? What's that?") right.
This approach is common enough in the DOS world. Just yesterday, I heard
one of our tech writers complaining about the need to have 6 versions of
Word for Windows on her machine, to handle docs that were produced using
all those different releases, and which "don't look very good" if loaded
by the wrong version of Word. Maybe we'll see the day when many machines
have 6 releases of tcl/tk sitting in different directories. It's already
happening with perl.
(There's also the "I can't put it in /usr/local/bin; I don't have the root
password" problem. ;-)
--
if (HEART(getenv("USER"),'C')) printf("Honk!\n");
print "Honk!\n" if &HEART($ENV{'USER'},'perl');
if {[HEART $env(USER)] == {tcl}} {button .h -text honk ; pack .h}
YOU 4TH HEART IF HONK THEN
Bruce O'Neel
wrote:
> In article <431hgl$m...@portal.gmu.edu> rmcc...@osf1.gmu.edu (Ricky L
McClanahan) writes:
> >Daniel Cade Bigler (big...@millenium.texas.net) wrote:
> >: In article <IRVINE.95...@hopi.ks.sysnet.com>,
> >: Chuck Irvine <irv...@ks.sysnet.com> wrote:
> >: >I have a Tcl/Tk application that I want to distribute, but I can't
> >: >assume that all potential users will have Tcl and Tk installed. Nor
> >: >can I assume that they will install it to run my application.
> >: [---snipped---]
>
> We had the same problem; it was made worse by the fact that some customers
> did have tcl/tk, but an older version than we were using. Our solution has
> been to include wish and the tk libraries in our packages. So as not to
break
> any other applications that need a different release of tk, we simply decree
> that our package must be installed in a specific diretory (or you can install
> it anywhere, and create a symlink with the required name). Thus, one package
> I'm working on has the acronym "NDC". Our scripts all start with
"#!/ndc/bin/",
> plus the interpreter name. This directory contains versions of wish
(and perl)
> that were built "knowing" that things are found in /ndc/bin and /ndc/lib,
> and it works pretty well.
>
I'll second this approach. We're careful to call our version of wish
something other than wish, and, we ship only source so we had to do a bit
of work to make all the different packages build on all the differnet
platforms we support. Most of our users are not computer people at all.
If it's more complex then
configure
make <with maybe a few flags>
we're out of luck.
Our application is really a shell script which starts up our wish with a
command line. Not quite so clean, but, it work.
bruce
Grant Reaber
interesting solution. You could right the program as a C program and
include the Tcl code as a string literal to be evaluated using Tcl_Eval
(which would be linked into your program). Then you could ship just a
single binary -- neat.
There may be limits on how big of a Tcl program this would work for.
Perhaps you could break the thing up into several strings. To save
memory, you might even be able to dynamically load modules with the
strings (of course then you might have more than one file).
Grant
Bob Jackson
make install
which creates a top level /bin/sh script with the appropriate
paths to 'tcl' and 'wish' and sets the required environment
variables, e.g., TCL_LIBRARY, TK_LIBRARY, TCLINIT, DP_LIBRARY.
The makefile block looks like:
install:
chmod 755 ./bin/bigtcl
TCL_LIBRARY=./initfiles/tclX ; export TCL_LIBRARY ; \
TK_LIBRARY=./initfiles/tk ; export TK_LIBRARY ; \
TCLINIT=./initfiles/tclX/TclInit.tcl ; export TCLINIT ; \
DP_LIBRARY=./initfiles/dp ; export DP_LIBRARY ; \
./bin/bigtcl ./distrib/install-binaries
This make the application independent of any other versions
of Tcl or Wish which are present.
Bob
Noelle Adam
The "image instance" concept of Tk 4.* is unclear to me.
If i1 and i2 are both image instances with the same master image,
how can they differ?
Is it possible that i1 and i2 have different attribute values?
Which attributes? How can I change them?
I have defined my own image type, providing
procs create,get,display,free, delete and I've registred them
with "Tk_CreateImageType".
Now I'd like to have different canvas items displaying the
same image with different viewing parameters, e.g. different zoom values.
From what I understand of the new image subsystem of Tk 4.0, I
could do it with one master image and several instance images, each of them
having a different zoom ratio (this ratio being stored in
a new MyTypeInstance struct field).
Is this feasible? Is there a "better" way to do it?
Thanks,
Noelle Adam