HDTenEightyP/NetNews huggingface dataset:
From: "David Herron" <david@twg.com>
Subject: Re: Can <Tab> be used to change focus in forms?
Sensitivity: Personal
Encoding:  39 TEXT , 4 TEXT 
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Wed, 18 Nov 1992 17:53:39 GMT

shite@sinkhole.unf.edu (Stephen Hite) writes:
>    When creating a dialog using the Tk Toolkit (with wish), is
>it easy to get the <Tab> key to act as a focus changer so a user
>could easily go from one field to the next without using the
>mouse?  That is, I'm looking for the functionality you'd get in a dialog
>with Microsoft Windows.  

Not without a lot of work.  I've done it, and the code is in an
easily separable module, so it can (and has been in the past) sent
out for distribution.

It works by declaring some places on the screen which can have focus.
The focus module keeps a list of places which can have focus and sets
up bindings so that <TAB> traverses them in a grand circle.  You can also
arrange for particular events to focus-traverse in other ways.  Focus is
indicated by modifying the relief of the frame widget enclosing the area
which can have focus, the frames are declared to have width=3 so that
the relief actually SHOWS UP.

I'm not satisfied with it

- It is possible to be indicating focus on a widget which does not
  have focus.

- It works differently than the MS-Windows & Motif way.  On those two
  the user is supposed to be able to reach and manipulate any widget
  using just the keyboard.  With my focus module you can only REACH
  widgets which have been declared to the focus module, and you can
  only MANIPULATE them in ways which are declared in Tk's bindings.

  For instance, Motif listboxes can be scrolled with the arrow keys
  and (by default) Tk's listboxes cannot.  It is possible to set focus
  on a listbox and have the arrow (and PgUp & PgDn) keys scroll
  it around.  But it is not this way by default.

If you want it posted, send mail to me at home (David Herron 
<david@davids.mmdf.com>) and I'll arrange to post it again or
maybe hand it to the archiver.


<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- During the '80s Usenet's mantra was: "Not all the world's a VAX".
<- During the '90s I hope it becomes:   "Not all the world's DOS (ick)".
From: libes@cme.nist.gov (Don Libes)
Newsgroups: comp.lang.tcl
Subject: Re: Expect can read its script from stdin, but then interact doesn't work
Date: 16 Nov 92 21:25:18 GMT
Organization: National Institute of Standards and Technology

In article <1992Nov12.202657.15587@midway.uchicago.edu> pynq@midway.uchicago.edu writes:
>I'm just curious if this is something that will be fixed or if it is a
>builtin deficiency.  I spent a fair amount of time tearing my hair over
>this one - I couldn't understand why my script was mysteriously
>terminating itself at the interact statement.
>
>My shell script was something like:
>
>	nawk '...' | expect -
>
>where nawk builds up the script and pipes it to expect.

This is (almost) funny.  The whole point of Expect is to get around
programs that make assumptions that the user must be reached via
/dev/tty.

>I would have expected stdin/stdout to be forced to something like
>/dev/tty before the interact is executed.  Is there some way I can cause
>this to happen?

Yeah, get an older version (:-) It actually used to work as you want
it to.  I ran into a case where that was clearly wrong.  So I changed
it.  I should've provided access for /dev/tty through a reserved
spawn_id.  I just didn't have the foresight.

How about "dev_tty_spawn_id"?  "devtty_spawn_id"?  "tty_spawn_id"?
("user_spawn_id" already refers to stdin/out.)

Don
From: libes@cme.nist.gov (Don Libes)
Newsgroups: comp.lang.tcl
Subject: Re: expect with tk
Date: 16 Nov 92 21:49:49 GMT
Organization: National Institute of Standards and Technology

In article <1992Nov12.182342.23404@crc.ac.uk> gwilliam@crc.ac.uk (Gary Williams x3294) writes:
}What I want to know is, how can I use them [Tk and Expect] at the same time?

In article <1992Nov12.182342.23404@crc.ac.uk> karl@NeoSoft.com (Karl Lehenbauer) writes:
}I don't recall anybody posting about having tried to combine them.
}Someone said it looked like a fair amount of work, and posted a
}pretty large list of things to do.

}For an application where I needed both I just launched expect from tk.
}Maybe you can do something like that.

It's on my to-do list (and probably a couple other people's).
Actually I suspect it's not that hard.  I always figured I'd do it as
soon as Expect settled down.  (You have no idea how many requests I
get for enhancements to Expect just by itself.)  One of these days...

Don Libes          libes@cme.nist.gov      ...!uunet!cme-durer!libes
Newsgroups: comp.lang.tcl
From: hcs+@cs.cmu.edu (Henry C Schmitt)
Subject: Re: Tk and Macintosh?
Summary: No Mac native Xlib?
Keywords: Macintosh Xlib
Organization: Engineering Design Research Center, Carnegie Mellon
Date: Sun, 22 Nov 1992 01:52:54 GMT

In article <Uf3Hat_00h5KF3frAz@cs.cmu.edu> Sean.Levy@cs.cmu.edu writes:
>Excerpts from netnews.comp.lang.tcl: 19-Nov-92 Re: Tk and Macintosh?
>"David Herron"@twg.com (2824)
>
>> - Write a native implementation of Xlib.  This by itself would be a big
>>   project, but once done Tk would have instant portability to that
>>   system.
>
>This seems by far the most preferable solution in the short term to me. 
>Clearly, the MacX server has to have code in it somewhere to translate X
>protocol requests to Macintosh calls (ddx or whatever they call it now).
>It's actually surprising to me that I haven't heard of Apple.COM
>splitting this functionality out and packaging it with a normal Xlib API
>(of course, this is harder than I just made it sound) -- they'd make a
>killing, wouldn't you think? Esp. from folks like us...
>

	Sorry, MacX is simply an X Terminal (i.e. a server, access
control, and window manager) which runs under the MacOS.  It has NO
support for X clients.  If you want to write X clients on a Mac, you
MUST get A/UX which includes the full X11R4.

	Also MacX does no translation into the native Mac environment.
For example, xterm still uses the goofy left-hand scrollbar with three
button control instead of the standard Mac scrollbar with up and down
arrows and a thumb with paging areas.

	I think the closest one can come to an Xlib on the Mac is
something like XVT.  Also, how does one handle the fact that X expects
a 3-button mouse and the Mac only has one?  I really dislike how MacX
does it (i.e. use the left and right arrow keys for the center and
right arrow keys respectively. UGH!).
-- 
Henry C. Schmitt
Home: 2863 Beechwood Blvd.,Pittsburgh, PA 15217-3114 (412) 421-8482
Work: 2212 Hamburg Hall,5000 Forbes Ave,Pittsburgh, PA 15213 (412) 268-2257
E-Mail: InterNet: hcs@cmu.edu CIS: 72275,1456 AppleLink, AOL, GEnie: H.Schmitt
Newsgroups: comp.lang.tcl
From: mdm@stegosaur.cis.ohio-state.edu (Michael Moore)
Subject: Re: Scrollable buttons?
Organization: The Ohio State University Dept. of Computer and Info. Science
Date: Tue, 17 Nov 1992 15:16:57 GMT

In article <1992Nov17.102654.15449@dxcern.cern.ch> trones@dxcern.cern.ch (Jostein Lodve Trones) writes:
>
>Any possibilities to get buttons part of a scrolling canvas?
>
>I have a lot of buttons to be displayed, and would like a scrollbar-feature
>to deal with this. But buttons on a canvas is no good, is it?
>I guess I could use rectangles on the canvas instead, but I kind of like the
>3D appearance of the buttons.
>

	You can do this.  Check out the demos that came with the
Tk distribution.  I was going to use this to implement a directory
viewer, but ran into some problems of my own with the canvas widget.

Here is the code that does this sort of thing :

frame .frame

scrollbar .frame.scroll \
    -command ".frame.canvas yview" \
    -relief raised

canvas .frame.canvas \
    -yscroll ".frame.scroll set" \
    -scrollregion {0 0 1200 10i} \
    -relief raised

pack append .frame \
    .frame.scroll    {left frame center filly} \
    .frame.canvas    {left frame center fillx filly}

pack append .\
    .frame   {left frame center fillx filly}

for {set i 0} {$i < 25} {incr i} {
    button .frame.canvas.button$i  \
	-relief raised \
	-text "Button $i"
    .frame.canvas create window 40 [expr $i*25] \
	-window .frame.canvas.button$i 
}


Run that through wish and watch what it does.

The problem I ran into was setting up the boundaries of the canvas.
I wanted to add and subtract buttons, and based on how many I had,
I needed to adjust the scrollregion height of the canvas and have the 
scrollbars react accordingly.

So maybe at one point in my program's execution I had 20 buttons
lined up vertically, so my scrollregion needed to be :
    
    {0 0 200 [expr 25*20]}

and then I removed them all and reconfigured it so that there
were then 14 buttons.  So I want the scroll region to be :

   {0 0 200 [expr 25*14]}

The difficulty I encountered was that the scrollbars did not
react to my minstrations with the scroll region.  I tried doing
a manual set command on the scrollbar but was unsuccessfull in
sending it the proper arguments.
 
If anyone might know of a way to do this please tell me.  I am
afraid I could not figure it out.  


        -Michael


-- 
|\  Michael  Delbert  Moore     _   /|     Home   : (614) 471-1937         /|
| \ OSU Student  Programmer     \`o_O'     Office : (614) 292-7161        / |
| / Undergraduate CIS major       ( )      Email  : mdm@cis.ohio-state.edu\ |
|/-------------------------        U       --------------------------------\|
Newsgroups: comp.lang.tcl
From: joe@morton.rain.com (Joe Moss)
Subject: Re: polling, nonblocking reads in tcl
Organization: Morton & Associates, Inc.
Date: Mon, 23 Nov 1992 18:51:20 GMT

mathew@elroy.Jpl.Nasa.Gov (Mathew Yeates) writes:

[...]

>2) It seems that the input is being buffered. Is this a consequence of
>the Tcl command "read" being built on top of fread instead of read?
>Often times, the program will hang at the select call as if there is
>no impending input (even though I know it is there). If I force some
>characters through the telnet connection, then the missing characters
>show but the ones I just sent do not. In other words, there is a delay.

Try adding this after the open call:

	fcntl $valkcon NOBUF 1
-- 
Joe V. Moss                             |   joe@morton.rain.com
Morton & Associates                     |  joem@m2xenix.psg.com
7478 S.W. Coho Ct.			|         - or -
Tualatin, OR 97062-9277                 |  uunet!m2xenix!morton!joe
Newsgroups: comp.lang.tcl
From: "David Herron" <david@twg.com>
Subject: Re: Tk and Macintosh?
Sensitivity: Personal
Encoding:  52 TEXT , 4 TEXT 
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Thu, 19 Nov 1992 23:57:22 GMT

I spent some time last summer looking at Tk and trying to get a feeling
for how easily it would port to other windowing systems ...

Tk, as it is currently implemented, uses X calls all through the library.
There are utility procedures in the library which, for instance, handle
text drawing and the 3D borders and so on.  Then the widgets don't have
much (or any, in some cases) X specific code to draw text or 3D borders.
And some of the widgets look to be very portable ...  But some are not.

Out at the script level Tk doesn't hardcode X concepts into its concepts.
Most of the commands are pretty generic but there are a few exceptions.
For instance, when you specify a font name it is in the X format
for font names.  Then the way one creates a modal dialog is by using
the `grab' command to make sure only the modal dialog window gets events;
the `grab' concept is something I've only seen in X.  These are the
two which come immediately to mind ..

There are three ways to proceed:

- Portable graphics and event handling library.  You'd knock some of the
  foundations out from under Tk's feet and rewrite things so that it
  used the low level drawing & event handling of the local system.  This
  looked like a lot of work on something with which I did not have a lot
  of experience, but it would definitely be an interesting project.

  One of the far fetched ideas I had at that time was to talk with some
  place like Software Tranformation (which already has a portable graphics
  and events library) to see if they might want to have a product which
  was a script-driven application writing system which was portable to
  the world...

  A downside of this is the resulting windows wouldn't look like normal
  windows.  Mac's have flat looking widgets while Tk's are 3d motif style.

- Wrapper to implement an interface to the native widgets using Tk (or
  Tk-like) commands.  The `button' (et al) command would create a little data
  structure which encapsulates the pointer returned by the native
  windowing system into a local data structure.  Other structure would
  be set up to turn native events into whatever we'd need to drive
  the script.

  But this also looked to be a big project.  The resulting programs would
  look like native programs though ...

- Write a native implementation of Xlib.  This by itself would be a big
  project, but once done Tk would have instant portability to that
  system.

  Fortunately we didn't need to write our own Xlib as we've found one
  for DOS.  Unfortunately it's been taking awhile to port that Xlib
  to the compiler we have on DOS.


<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- During the '80s Usenet's mantra was: "Not all the world's a VAX".
<- During the '90s I hope it becomes:   "Not all the world's DOS (ick)".
Newsgroups: comp.lang.tcl
From: "David Herron" <david@twg.com>
Subject: Re: Wanted: Geometry handlers like TeX Glue...
Sensitivity: Personal
Encoding:  27 TEXT , 4 TEXT 
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Wed, 18 Nov 1992 00:37:56 GMT

Note: I do not have much direct experience with TeX's box+glue.  But
I have read the TeXBook, and the section of the Interviews manual which
talks about their geometry handler which is box+glue based.  I also used
the latter as a guide in writing my own box+glue geometry handler for
use within XVT based applications.

The packer is a whole lot like box+glue without some of the richness.
Objects placed within the packer can only (easily) be placed along
one axis.  To get a complicated layout you use multiple frames and
pack each frame differently.

This isn't to say that I don't want a more powerful and/or easier
to use geometry handler in Tk (because I do).  But I'm not convinced
that the box+glue paradigm is wonderful nor is it everything that one
might want.

Other toolkits with which I have experience have

row-column for enforcing an array-like layout.  This is used mostly
for menus however.

`form' to handle fancy arrangements where one describes the layout
with attachments to other widgets on the screen.

`table' to do a tbl style layout.  You give a pattern to use in placing
the widgets, then create the widgets.


<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- During the '80s Usenet's mantra was: "Not all the world's a VAX".
<- During the '90s I hope it becomes:   "Not all the world's DOS (ick)".
Newsgroups: comp.lang.tcl
From: trones@dxcern.cern.ch (Jostein Lodve Trones)
Subject: Button-size in pix's or frame-size in char's?
Reply-To: trones@dxcern.cern.ch (Jostein Lodve Trones)
Organization: CERN, European Laboratory for Particle Physics, Geneva
Date: Mon, 16 Nov 1992 10:28:38 GMT


I hope somebody out there can help me with the following problem...

I am going to open a frame containing some buttons in columns and rows.
Since I will do this quite often, and with a different number of buttons,
I am writing a procedure to do this.

I use place instead of pack, because I want a somewhat speciall lay-out, 
with space around the buttons.

The problem is that I need to know the size of the frame before I open it.
But to calculate the size of the frame, I need to know the size of a button.
The button's size is known in characters, but not in pixels.

I thought of using the winfo command to return the button-size in pixels,
but this do not work, unless the button is already placed or packed in
the frame, and the frame already packed/placed on the root-window, or 
another packed/placed window.

So I have the famous "chicken-and-the-egg" problem: I can not calculate
the size of the button, unless the frame is opened, and I can not open
the frame unless I know the size of the button...
(With "open" I mean place/pack the window so that it is visible on the screen)

I could of course first place the frame, then place a button on it, find
the size and regeometrize(?) the frame, but is there a better way?

What I actually need, is a way to get the button's size in pixels when
I know the size in characters, or a way to specify the frame-size in 
characters.


Thank you for any help!

Cheers,
        Jostein
Newsgroups: comp.lang.tcl
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: Re: Scrollable buttons?
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Tue, 17 Nov 1992 13:47:36 GMT

The hypertext widget (on barkley.berkeley.edu) can scroll buttons in a window.

The manpage for the text widget (standard in Tk) says that the ability to
include arbitrary windows within text widgets will be available in a future 
release.
-- 
-- Email info@NeoSoft.com for info on getting interactive Internet access.
"Turn on your hot tub by email now.  Ask me how."
From: bagwill@swe.ncsl.nist.gov (Bob Bagwill)
Newsgroups: comp.lang.tcl
Subject: SOURCE - man.tk - gross little hack
Date: 17 Nov 92 22:29:48 GMT
X-Newsreader: TIN [version 1.1 PL6]

Here's an amusing little abuse of menus.  It has the obvious bug
of not handling too many man entries.  Enjoy.

#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  man.tk
# Wrapped by bagwill@swe on Tue Nov 17 17:25:15 1992
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'man.tk' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'man.tk'\"
else
echo shar: Extracting \"'man.tk'\" \(1422 characters\)
sed "s/^X//" >'man.tk' <<'END_OF_FILE'
X#!/usr/local/bin/wish -f
X####################################
X# man.tk
X# man page viewer hack
X# Bob Bagwill - no rights reserved
X####################################
set sections {1 2 3 4 5 6 7 8 l n}
set ALPHABET {A B C D E F G H I J K L M N O P Q R S T U V W X Y Z}
set alphabet {a b c d e f g h i j k l m n o p q r s t u v w x y z}
set Alphabet [concat $ALPHABET $alphabet]
X
set mandir /usr/man/man
X
proc display page {
X	catch {destroy .$page}
X	toplevel .$page
X	wm minsize .$page 80 25
X	button .$page.ok -text OK -command "destroy .$page"
X	text .$page.text -setgrid true -yscroll ".$page.scroll set"
X	scrollbar .$page.scroll -command ".$page.text yview"
X	pack append .$page .$page.ok {bottom fillx} \
X		.$page.scroll {right filly} .$page.text {fill expand}
X	.$page.text insert 1.0 [exec man -D $page]
X}
X
wm title . man
X
foreach h $sections {
X	frame .$h
X	label .$h.l$h -width 8 -relief raised -text $h
X	pack append .$h .$h.l$h left
X	foreach i $Alphabet {
X		if {[glob -nocomplain $mandir$h/$i*] != ""} {
X			menubutton .$h.$i -text $i -menu .$h.$i.m
X			pack append .$h .$h.$i left
X			menu .$h.$i.m
X			foreach j [lsort [glob -nocomplain $mandir$h/$i*]] {
X				if {$j != ""} {
X					set manpage [file root [file tail $j]]
X					.$h.$i.m add command -label $manpage -command "display $manpage"
X				}
X			}
X		}
X	}
X	pack append . .$h {top fillx}
X}
bind all <Control-q> {destroy .}
X################
X# end of man.tk
X################
END_OF_FILE
if test 1422 -ne `wc -c <'man.tk'`; then
    echo shar: \"'man.tk'\" unpacked with wrong size!
fi
chmod +x 'man.tk'
# end of 'man.tk'
fi
echo shar: End of shell archive.
exit 0
--
Bob Bagwill
bagwill@swe.ncsl.nist.gov
From: damurphy@wc.novell.com (Duane Murphy)
Newsgroups: comp.lang.tcl
Subject: Tk and Macintosh?
Date: 19 Nov 92 18:22:49 GMT
Article-I.D.: novell.1992Nov19.182249.21095
Organization: Novell, Inc.
X-Xxdate: Thu, 19 Nov 92 18:26:54 GMT
X-Useragent: Nuntius v1.1.1d12

So far our use of Tcl has been as a scripting environment only.  We have 
not tried to use it for what Mr. Ousterhout describes as a particularly 
important use for Tcl; that is as a script based interface into a 
windowed graphical environment.

There has obviously been a lot of work done on Tk.  My experience is 
virtually null (ok not virtually, it is null) on XWindows (I know what it 
is but I have never used it or programmed it).  I am looking for ideas on 
how Tcl would fit into the GUI of the Macintosh.  Should I look at Tk as 
a starting point for a Tcl interface or should I do something completely 
different for the Macintosh?

My premise is that Tk might be interesting to look at to see how some of 
the problems have been dealt with in that environment and then adapt 
them to the Macintosh environment.  

Any comments, opinions, and advice would be very helpful.

Thanks,
...Duane

  +------------------------+--------------------------------------------+
  | Duane Murphy           | My opinions are mine, mine, and only mine; |
  | damurphy@wc.novell.com |      Except when they are also yours.      |
  | Macintosh Software QA  |                                            |
  +------------------------+--------------------------------------------+
From: pynq@quads.uchicago.edu (George Jetson)
Newsgroups: comp.lang.tcl
Subject: Expect: Why doesn't interact have the -re flag?
Summary: Or, is there any way to do explicit I/O to a spawn'd task?
Date: 16 Nov 92 02:36:11 GMT
Reply-To: pynq@midway.uchicago.edu
Organization: D. J. Dougherty & Associates

I would like to be able to either match strings with reg exps in
interact (and be able to check back to see exactly what was matched)
a la expect (with -re).  I could see no way to do this.

Alternatively, if I could do an explicit I/O that would work, too, a la:

interact {
	-o foo	{ somekindofreadstmthere spawn_id var
		if {var == "bar"} ...
		if {var == "d"} ...
		}
	}


Well, you get the idea...

Any ideas, or do I have to write C code?
(I am using Tcl6.4, and expect 3.23.0)

************************************************************************
I've been told to back off on the diode jokes, but I still don't
like smileys ;-)

	- pynq@quads.uchicago.edu, who is still costing the net
	  hundreds, if not thousands, of dollars, every time he posts -
************************************************************************
From: chris@yen.IMSI.COM (Chris Payne)
Newsgroups: comp.lang.tcl
Subject: Re: Dumping/Restoring Interpreter Memory
Date: 16 Nov 92 01:25:26 GMT
Distribution: usa
Organization: Moore Capital Management
In-reply-to: karl@NeoSoft.com's message of 12 Nov 92 06:54:30 GMT
Originator: chris@yen


gdb (version >= 4.7 if not earlier) does something like this.  It uses
a new gnu malloc system which allows for multiple malloc pools -- the
app can specify a pool when it calls malloc.  gdb uses a special pool
for programs' symbol-tables which it can save as a disk file.  These
files can be reloaded later by another instance of gdb.

The scheme uses mmap'd files for malloc arenas -- fast & popular these
days, if your operating system provides it (sunOS, SGI's irix, sVr4...)

To make this work for Tcl, you'd have to grab the gnu package & then
identify the malloc's for variables you want to save.  You might have
to convert some [static] structures to live in the mmap'd area.  The
reload won't be super-clean, either.

Good hunting.

/chris