HDTenEightyP/NetNews huggingface dataset:
From: awu@cisco.com (Andrew Wu)
Subject: Tk tutorial
X-Disclaimer: The views expressed in this message are those of an
	      individual at SRI International, and do not necessarily
	      reflect those of the company.
Organization: cisco Systems, Incorporated
Date: Tue, 8 Sep 1992 03:34:37 GMT

I'm new to Tk.  I'd like to know wether there are any Tk tutorial to help me get start with it.

Thanks in advance.

Andrew Wu



Newsgroups: comp.lang.tcl
From: gillies@noao.edu (Kim Gillies)
Subject: tclIPC library on archive
Keywords: TCL ipc
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Date: Sat, 12 Sep 1992 00:32:24 GMT


I've just uploaded my tclIPC package to barkley.berkeley.edu.  It
should appear as /tcl/extensions/tclipc-1.0.tar.Z shortly.

Here's some information from a README.
-----------------------------------------------------------------------
tclIPC is a library that implements a send command for TCL similar to
the "send" command in Tk, but it does not require Tk or X11.  TCL/tclIPC 
programs can connect to other TCL/tclIPC programs and execute commands in their 
interpreters and use the results locally.  The communication model is
peer-to-peer, different than most client-server libraries that are around.

The tclIPC distribution consists of the source and some additional directories
containing some test applications and a required application called the
PortManager.  The tclIPC library can be used with GUI libraries including
Tk, XView, and OLIT (probably Motif, but I don't have it).

tclIPC features:
 -simple to use from TCL scripts
 -includes TCL script access and C language interface
 -supports "send" in command-line programs
 -supports GUI toolkits and includes examples for Tk, XView, and OLIT.

Acknowledgements
----------------------------------------------------
Much of this library is based on work done by George Drapeau as part
of the MAEstro Project.  MAEstro is a distributed multimedia environment
built to focus on student authorship of multimedia documents.  The
source for MAEstro is on sioux.stanford.edu.  

Requirements
----------------------------------------------------
tclIPC is an extension to TCL, so you must already have TCL.  In fact,
you must have TCL 6.4 since tclIPC uses the new Tcl_GlobalEval procedure.
Tcl is available on sprite.berkeley.edu.

You must have an RPC implementation compatible with Sun RPC 4.0 available
on titan.rice.edu.  You need a version of rpcgen.

tclIPC uses the handles part of the Extended Tcl package.  The
important files are included in the tclIPC distribution if you don't
have or use Extended TCL.

tclIPC will compile with gcc2.2.2 or Sun's cc or acc.  It has only been tested
on the Sun platform (versions 4.1.1 and 4.1.3 SunOS), but should port to
machines with an RPC implementation like Sun's.

----------------------------------------------------
Reporting Errors, Suggestions for Improvements, Etc

If you find an error in any of the tclIPC code or would like
to discuss the code or improvements, please send mail to:

	gillies@noao.edu

	Kim Gillies
        National Optical Astronomy Observatories
        950 North Cherry
        Tucson, Arizona   85719
        602-325-9246
-- 
Kim Gillies, National Optical Astronomy Observatories, Tucson, Arizona USA
Internet: gillies@noao.edu  phone: 1 602 325 9246
Newsgroups: comp.lang.tcl
From: kelsey@mdd.comm.mot.com (Joe Kelsey)
Subject: Bug in extended Tcl: LoadPackageIndexes
Summary: Loads *last* package in a path instead of *first* package in a path.
Keywords: TCLPATH auto_path TCLSH LoadPackageIndexes demand_load
Organization: Motorola, Mobile Data Division - Seattle, WA
Date: Tue, 15 Sep 1992 22:17:03 GMT

Extended TCL searches through the TCLPATH looking for files named *.tlib.
Whenever it finds one, it loads the package index.  At the end of this
process, it then looks for defined procs.  If you use TCLPATH, expecting it to
operate like PATH, with an earlier instance of a name superseding a later
instance of a name, you can expect surprises!  The problem occurs if you try
to test a new package by placing it in a directory path in front of the
standard path, for example, 

set TCLPATH {../local /usr/local/lib/tcl /usr/local/lib/tk}

Then place test.tlib in ../local, with the ``official'' version in
/usr/local/lib/tcl.  The TCLSH:LoadPackageIndexes command uses the full
pathname to determine if it already loaded a package instead of the last file
name, thus resulting in the last package encountered becoming the loaded
package!  I think the problem occurred because the ``Ouster'' style indexing
allows only one index per directory, while the extended package concept places
an index per package library file.

I fixed the problem by changing the TCLENV(LOADED:xxx) array element to
mention just the package name rather than the full path name:

*** extended/tcllib/TclInit.tcl.orig	Sat Aug 22 09:26:56 1992
--- extended/tcllib/TclInit.tcl	Tue Sep 15 13:22:14 1992
***************
*** 58,69 ****
  # Load library indexes along path.
  #
  proc TCLSH:LoadPackageIndexes {path} {
!     global TCLPATH TCLENV
      foreach dir $path {
          foreach libFile [glob -nocomplain $dir/*.tlib] {
!             if ![info exists TCLENV(LOADED:$libFile)] {
                  loadlibindex $libFile
!                 set TCLENV(LOADED:$libFile) 1
              }
          }
          if {[file readable $dir/tclIndex] && ![info exists TCLENV(LOADED:$dir/tclIndex)]} {
--- 58,70 ----
  # Load library indexes along path.
  #
  proc TCLSH:LoadPackageIndexes {path} {
!     global TCLENV
      foreach dir $path {
          foreach libFile [glob -nocomplain $dir/*.tlib] {
! 	    set libName [string range $libFile [expr [string last / $libFile]+1] end]
!             if ![info exists TCLENV(LOADED:$libName)] {
                  loadlibindex $libFile
!                 set TCLENV(LOADED:$libName) 1
              }
          }
          if {[file readable $dir/tclIndex] && ![info exists TCLENV(LOADED:$dir/tclIndex)]} {

/Joe

Newsgroups: comp.lang.tcl
From: chare@unilabs.uucp (Chris Hare)
Subject: compiling for SCO ODT 2.0
Organization: UniLabs Research Group
Date: Tue, 15 Sep 1992 23:04:26 GMT

I don;t have the error messages right here in fromt of me, but I got a
bunch of them when I tried to compile this last week.  Can anyone procide
any tips to making this work?

Thanks!
-- 
????                --- It Always works for me! ---                           
Chris Hare, UNIX Scientist                  Preferred : chare@unilabs.uucp
Just a mild-mannered consultant by day ....
From: ouster@sprite.Berkeley.EDU (John Ousterhout)
Newsgroups: comp.lang.tcl
Subject: Re: Compiling tcl 6.3 with gcc 2.2.2
Date: 7 Sep 1992 22:21:18 GMT
Organization: U.C. Berkeley Sprite Project
Distribution: world
NNTP-Posting-Host: tyranny.berkeley.edu

In article <17oqn8INNkhj@agate.berkeley.edu>, jbuck@forney.berkeley.edu (Joe Buck) writes:
|> In article <1992Aug29.112757.11363@athena.mit.edu> joe@athena.mit.edu (Joseph C Wang) writes:
|> >I've also noticed bugs you mentioned (needing -fno-builtin and
|> >redefining open) on all the platforms I have gcc2.2 on (decmips, vax,
|> >and rt)
|> 
|> This is a Tcl bug, as ANSI C and Posix have agreed on what the prototype
|> for open and other functions is, and the Tcl prototypes don't agree with
|> the standard.  gcc's builtin definitions and those it builds with the
|> "fixincludes" script are correct; Tcl is wrong.
|> 
|> 
|> 
|> --
|> Joe Buck	jbuck@ohm.berkeley.edu

I don't understand this, since I believe that the prototypes for open
and other ANSI functions are identical to what's specified in my ANSI C
and POSIX manuals.  Can someone provide a bit more detail on exactly
what the error is?
Newsgroups: comp.lang.tcl
From: lwv26@cas.org (Larry W. Virden)
Subject: Re: errors in Tk2.3 demos
Followup-To: comp.lang.tcl
Reply-To: lvirden@cas.org (Larry W. Virden)
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Fri, 11 Sep 1992 14:02:22 GMT

In article <gaier.715519549@nova> gaier@nova.tat.physik.uni-tuebingen.de (Karsten Gaier) writes:
:gwlester@cpu.com (Gerald W. Lester) writes:
:
:>In article <9209012315.AA06051@MATH13.CIMS.NYU.EDU>, walkerm@MATH13.CIMS.NYU.EDU (M.Walker) writes:
:>> ...
:>>invalid command name "tk_bindForTraversal"
:>>	while executing
:>> ...
:>>Are there any changes I need to make?  Since I cannot install things in such 
:>>places as /usr/local or /usr/lib, I installed the Tcl and Tk respectively in
:>>$HOME/lib/tcl and $HOME/lib/tk where $HOME is /stumpy.a/misc/walkerm (along
:>Michael,
:
:>	Sounds like you should check your tklibrary and tcllibrary variables.
:
:I had the same problem. In wish.tcl you have to load some other files:
:
:source [info library]/init.tcl


I don't know about you other folk, but OUR problem, when this occured, was
that we had not copied the tk tclIndex file from the distribution's library
directory into the install location!  As soon as we did, the invalid command
name problems went away.

Also, something occured to me this morning.  If someone is trying to 'save
some space' by combining the various library directories, you may get
yourself in trouble if you do not concatenate the various tclIndex files!

-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
America Online: lvirden@aol.com
Newsgroups: comp.lang.tcl
From: jamensky@bnr.ca (Mark Jamensky)
Subject: Help: Reverse video in app defaults
Reply-To: jamensky@bnr.ca (Mark Jamensky)
Organization: Bell-Northern Research Ltd.
Date: Wed, 9 Sep 1992 15:43:10 GMT

(Sorry about the double internal posting, but my distributon was set to BNR only)

  I'm using the loadAppDefaults supplied in the FAQ and I'd like to set default
fonts, colors, etc.  I've created a file in /usr/lib/X11/app-defaults called 
Test.  In it I have the following:

*font:        10x20
*background:  black
*foreground:  white 

  I call "loadAppDefaults Test" and then I source in my script.  As expected the
fonts of all my widgets change to the one specified.  Unfortunately the widgets
still do not appear in reverse video.

  Ideas anyone?


-- 
Mark Jamensky   jamensky@bnr.ca   Bell-Northern Research   Ottawa
From: eo@ansa.co.uk (Ed Oskiewicz)
Newsgroups: comp.lang.tcl
Subject: can you reset relief on listbox entries?
Date: 11 Sep 92 16:58:12 GMT


I'm constructing a long listbox and would like to pack the lines closer
together than the default. The problem seems to be that the entries have the
equivalent of -relief raised set by default, i.e. when selected they display
relief which seems to account for the unwanted separation. Is there any way to
make the default be -relief flat?

Cheers,

Ed Oskiewicz

email:	eo@ansa.co.uk (mcsun!uknet!ansa!eo)	ANSA,
tel:	+44 223 323 010				Poseidon House,
fax:	+44 223 359 779				Castle Park,
						Cambridge CB3 0RD, UK
Newsgroups: comp.lang.tcl,news.answers
From: kennard@tukey.berkeley.edu (Kennard White)
Subject: Tcl/Tk reader available
Organization: U.C. Berkeley -- ERL
Distribution: ucb
Date: Fri, 11 Sep 1992 17:21:44 GMT


(Ignore this if you're not in the Berkeley area.)

I have put together a tcl/tk reader. It contains 6 sections:
	Tcl Usenix paper, Tcl commands, Tcl C interface, and
  	Tk  Usenix paper, Tk command, Tk C interface.
All papers are from Tcl 6.4 and Tk 2.3, which, last time I checked :-),
were the latest.

I dont know the exact cost, but the previous version we did cost about $15,
so I would guess $15-$20 for this one.  It is spiral bound with clear
plastic front and back.

It is available at the Northside Copy Central in Berkeley under the name
"Tcl/Tk".  They are holding off the initial printing until I give them
an estimate of the number of readers wanted.  So, if you will be purchasing
one, please send me mail (kennard@ohm.berkeley.edu) or call me (643-6686).
All money is between you and CopyCentral: Im just counting heads.

For reference, Northside Copy Central is at 1862 Euclid w/phone 510/849-9600.

Kennard
Newsgroups: comp.lang.tcl
From: normanb@citi.umich.edu (David R. Richardson)
Subject: scrollbar styles
Reply-To: normanb@citi.umich.edu
Organization: IFS Project, University of Michigan
Date: Thu, 10 Sep 1992 15:08:18 GMT

Has anyone come up with a way for Tk scrollbars to behave in a style similar
to Athena scrollbars?  I am especially interested in the Athena features
of:

    Button 1 or 3 to move up or down, respectively,
    Amount of page to scroll dependent on where cursor is located
	in the scrollbar,
    Middle button to move to arbitrary location in document, without
	having to explicitly grab the slider.

Maybe it's just familiarity from longer use, but I find the Athena
behaviour more convenient and richer than the up and down arrows
at each end of the Tk scrollbars.


-- 
david richardson		Institutional File System Project
normanb@citi.umich.edu		The University of Michigan
From: eo@ansa.co.uk (Ed Oskiewicz)
Newsgroups: comp.lang.tcl
Subject: Re: Bug in menus of radio buttons
Date: 11 Sep 92 16:53:26 GMT


John,

Thanks for responding, a couple of people pointed out the -variable switch to
me. However I think the situation is still a bit confusing to the unwary and
maybe could be clarified in the documentation. I can (now) appreciate the
value of grouping radio buttons logically independantly of their placement in
a menu or packing order in a frame. But this notion of radio button group
seems quite crucial and is not really brought out in the documentation.

However the existing behaviour seems to me to be idiosyncratic, my suggestion
for 'less surprising' behaviour is as follows. First change -variable to
-buttongroup (or something more reminiscent of what is going on), second by
default (i.e. when -buttongroup is not specified) arrange that radio buttons
are grouped according to where the user places them, if in a menu all those in
the menu form a group, if in a frame all those in the frame form a group and
so on. It should be easy to fabricate a unique buttongroup name

Also, if you remember my original confusion was compounded by the discovery
that adding a space to the labels caused the two menus to act independantly.
Thus it seems that within a radio button group that adding a button with the
same label as an existing label causes it to be regarded as though it were
'the same' as the first instance, wouldn't an error be more appropriate as the
resulting behaviour is not what the programmer thought was going to happen?

Cheers,

Ed Oskiewicz

email:	eo@ansa.co.uk (mcsun!uknet!ansa!eo)	ANSA,
tel:	+44 223 323 010				Poseidon House,
fax:	+44 223 359 779				Castle Park,
						Cambridge CB3 0RD, UK
From: ouster@sprite.Berkeley.EDU (John Ousterhout)
Newsgroups: comp.lang.tcl
Subject: Re: varargs problem in Tcl_AppendResult()?
Date: 14 Sep 1992 22:44:56 GMT
Organization: U.C. Berkeley Sprite Project
Distribution: na
NNTP-Posting-Host: tyranny.berkeley.edu

In article <1992Sep14.021944.17302@sctc.com>, scott@sctc.com (Scott Hammond) writes:
|> Re: tcl6.4 on Sun4 (SunOS 4.1.2) built with 'cc'
|> 
|> Using a simple loop that reads single lines from the user and passes
|> them to the same interp via Tcl_Eval(), I entered the following:
|> 
|> 	? proc testhis {} { uplevel 1; set x 5 }
|> 	result: ''
|> 	? testhis
|> 	err result: 'wrong # args: should be "'
|> 	wrong # args: should be "
|> 	    while executing
|> 	"uplevel 1"
|> 	    (procedure "testhis" line 1)
|> 	    invoked from within
|> 	"testhis"
|> 
|> 
|> result is the value of interp->result.  err result is
|> the same after error detected, followed by information
|> from Tcl_GetVar() on errorInfo.
|> 
|> My concern is that the error message is truncated, which
|> means the varargs stuff in Tcl_AppendResult() isn't working.

Not to worry.  It's just a silly bug in the "uplevel" command where it
goofed up its error messages under the conditions you created.  I've fixed
it in my unrleased sources now.  Here's a patch to tclProc.c in case
you need the fix before the next Tcl release:

*** /tmp/,RCSt1543560	Mon Sep 14 15:43:29 1992
--- tclProc.c	Mon Sep 14 15:42:29 1992
***************
*** 289,294 ****
--- 289,297 ----
  	return TCL_ERROR;
      }
      argc -= (result+1);
+     if (argc == 0) {
+ 	goto uplevelSyntax;
+     }
      argv += (result+1);
  
      /*
***************
*** 302,310 ****
       * Execute the residual arguments as a command.
       */
  
-     if (argc == 0) {
- 	goto uplevelSyntax;
-     }
      if (argc == 1) {
  	result = Tcl_Eval(interp, argv[0], 0, (char **) NULL);
      } else {
--- 305,310 ----

Newsgroups: comp.lang.tcl,news.answers
From: dhami@cs.ubc.ca (Mandeep S Dhami)
Subject: Re: wish -- command line editing
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Date: Sat, 5 Sep 92 07:33:37 GMT

Also checkup GNU's readline library (comes with bash, al least). Very
easy to use and it is easy to hook up command line editing to any
program (with some 300K extra code!). Hope it helps. (In fact, I hooked
up some seemingly non-trivial code using GNU readline library and
tcl's interpreter almost painlessly!).

Mandeep.
__________________________________________________________________
"I'm very brave generally," he went on in a low voice:
"only to-day I happen to have a headache."
                                      -- Lewis Carroll
__________________________________________________________________
Newsgroups: comp.lang.tcl
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: Re: Periodic Actions in Tcl/Tk
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Mon, 07 Sep 1992 17:15:34 GMT

In article <VEK.92Aug31115650@rover.allegra.att.com> vek@allegra.att.com (Van Kelly) writes:
>What is the best way to define a period action (say, once every n seconds)
>in a Tcl/TclX/Tk environment, given that there may be a number of these
>one might wish to set up and later selectively cancel at a later date.

>The first thing I thought of was to have a global variable, say FOO,
>containing the code for a periodic action followed by an after command
>to re-evaluate itself.  But this is obviously tail-recursive and may
>explode its stack pretty fast.  

It isn't tail-recursive, it is still iterative.  The "after" command simply
schedules some command to execute later, so it is fine for a procedure
to reschedule itself with "after".
-- 
-- Email info@NeoSoft.com for info on getting interactive Internet access.
You will now awaken feeling relaxed and refreshed, remembering everything 
you've read except the details of the Omega contingency plan.
Newsgroups: comp.lang.tcl
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: Re: wish -- command line editing
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Mon, 07 Sep 1992 17:28:53 GMT

I've thought about adding some tcsh-like command line editing to Extended
Tcl, and will outline my ideas below.  Mark Diekhans has pretty much talked
me out of doing it by convincing me that Tcl is a programming language and
not a shell, but hey, that's not to say that it wouldn't be a worthwhile
project.

I added a new Tcl command, written in C, called "getkey" which lets you
read single keys from the user's keyboard.

The idea is that when some magic key is hit, you would try to do command
or filename completion.

To do command completion, let's say we're building up the word the user
is typing by repeatedly appending characters to a variable called "command".

When the user hits the meta key, a possibly incomplete command name is
in "command", so we do a "info commands $command*" and look at what is
returned.  If no elements are returned, you have an invalid command name.
If only one element is returned, you have a unique command
name.  If more than one is returned, you still have multiple matches, and
may offer them to the user a la command completion in the cmushell under
EMACS.

Note that with the autoloading capability of Tcl, a valid command name may
not be present but would be loaded once you tried to execute it, so you'll
have to look at the Tcl code that handles autoloading and peek into its
arrays to see if the command exists.

For filename completion, play the same tricks with "glob" instead.
-- 
-- Email info@NeoSoft.com for info on getting interactive Internet access.
You will now awaken feeling relaxed and refreshed, remembering everything 
you've read except the details of the Omega contingency plan.
From: colas@trinidad.inria.fr (Colas Nahaboo)
Newsgroups: comp.lang.tcl
Subject: Re: On my wishlist: tk-"wafe"
Date: 14 Sep 92 09:00:32 GMT
Organization: Koala Project, Bull Research France

In article <1992Sep11.075450.28546@wisipc.weizmann.ac.il>,
dov@menora.weizmann.ac.il (Dov Grobgeld) writes:
|> Someone recently asked for a Perl-version of TK in the comp.lang.perl
|> newsgroup, but I'm a bit more modest. I'll be happy enough if there
|> is an easy way to communicate between Perl and TK in TCL.

In fact, due to the nice design of Tk, It IS very easy to link Tk with another
interpreter instead of tcl.
We have just done this for Wool (a lisp-like dialect), and it was suprisingly
easy. So, if you can persuade perl experts to have a go at it, it should not
take them very long (a week?)

And, before people ask, yes we will make this version publicly available, in
about a month for the realease of the wool2 language...

-- 
Colas Nahaboo, colas@sa.inria.fr, Bull Research Koala proj. Wool&Gwm Architect
Pho:(33) 93.65.77.70(.66 Fax), INRIA, B.P.93 - 06902 Sophia Antipolis, FRANCE.
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.tcl
Subject: Re: Compiling tcl 6.3 with gcc 2.2.2
Date: 8 Sep 92 23:50:57 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu


In article <1992Aug29.112757.11363@athena.mit.edu> joe@athena.mit.edu (Joseph C Wang) writes:
>|> >I've also noticed bugs you mentioned (needing -fno-builtin and
>|> >redefining open) on all the platforms I have gcc2.2 on (decmips, vax,
>|> >and rt)
>|> 

I wrote:
>|> This is a Tcl bug, as ANSI C and Posix have agreed on what the prototype
>|> for open and other functions is, and the Tcl prototypes don't agree with
>|> the standard.  gcc's builtin definitions and those it builds with the
>|> "fixincludes" script are correct; Tcl is wrong.

In article <18gkkuINN73l@agate.berkeley.edu> ouster@sprite.Berkeley.EDU (John Ousterhout) writes:
>I don't understand this, since I believe that the prototypes for open
>and other ANSI functions are identical to what's specified in my ANSI C
>and POSIX manuals.  Can someone provide a bit more detail on exactly
>what the error is?

In compat/string.h, strcmp and a few other functions are declared to
return int.  ANSI says they return size_t.  But this header isn't
ordinarily used unless the configuration step thinks the system one is
invalid.  (Unfortunately, if you use gcc during configuration it will do
just this, so you'll then need to use -fno-builtin).  This problem
doesn't show up on Suns because Sun made size_t int, even though
it is supposed to be an unsigned type (objects cannot have negative sizes).

The problem with "open" turns out not to be that the prototype was invalid,
so I was in error.  The problem with "open" is that <sys/file.h> is
included before the prototype for open in tclUnix.h.  gcc is unhappy if
it first sees a prototype declaration that contains an ellipsis, and then
sees a declaration for the same function with no prototype.  That is,
it sees

extern int open();
...
extern int open(const char* path,int flags,...);

It will accept these two lines if they appear in the reverse order, but
not in this order.  If the full prototype does not have "...", gcc will
take any mixture of the non-prototype declaration and the prototype
version.

The gcc people claim that accepting both declaration forms for the
same function in the same compilation is actually an extension, so I
can't claim that rejecting this one is a bug.  Just the same, since the
input

extern int open(const char *path, int flags, ...);
...
extern int open();
...
extern int open(const char *path, int flags, ...);

also produces the error, it appears that at least in this case the
gcc trick to allow prototype- and non-prototype-declarations to be
mixed doesn't work as one would expect.




--
Joe Buck	jbuck@ohm.berkeley.edu