csw@ulysses.UUCP (07/07/87)
Is anyone else working on a psterm-like tool? I have been making
modifications but I don't want to go too far only to have someone
release a much improved version next week.
So far I have made the following modifications and fixed some bugs:
- always come up with the same size font regardless of the window
size. The number of lines and columns are set appropriatly
depending upon the size of the window. Font size is under user
control from a menu. To some this may seem like a step
backward, however in my area, at least, people are used to this
type of behavior from the 5620 windows. I make large windows to
fit more on the screen, not because I'm going blind and want a
big font.
There are a class of problems that crop up when dealing with
termcap entries that explicitly mention screen size. For
example, our vt100 entry sets the bottom of the scrolling region
to be at line 24 as part of its cleanup code. Naturally this
causes real problems if the window happens to be longer than 24
lines. For most applications, though, setting the lines and
columns through an ioctl seems to be all that is needed.
- use the user's interrupt character. For some reason psterm as
distributed carries forward your kill and erase characters but
not your interrupt. It always uses the default ^C. Strange.
- Change the scrolling behaviour so the screen does not jump
so much. This simply involves updating the screen after each
scrolled line instead of after a bunch of them. The result is
slower scrolling but that is what I wanted anyway.
Can others suggest additional features to make psterm into a more
useful terminal emulator?
And what would research be without a useless project too? Here's my
contribution.
Included below is jump.ps. It is a very simple program that creates a
fixed size window at a fixed location on the screen. Each time the
mouse enters the window the window jumps away to a random location on
the screen. Trying to kill one of these windows can be a frustrating
experience. It is especially amusing if you use the "setnewshome"
facility to cause the jumping window to pop up on another user's
screen.
Since the jumps are random, the window eventually makes a mistake and
jumps right on top of the mouse again. At that point it can be
ZAPped.
With this in mind perhaps someone can tell me how to do what I really
want. I want the window to be sensitive to other windows landing on
top of it, not just the mouse. I envision several of these
non-overlapping jumping windows on the screen together. The mouse
moves causing one of the windows to jump. It lands on top of another
window (or windows) which jump away. They in turn land on other
windows and the shifting continues until a steady state where no
windows overlap is once again acheived.
Can anyone suggest a way for a window to know when another window has
landed on top of it? The /Damaged event is almost exactly the
opposite of what I want - it detects when one window has jumped *off*
another. Perhaps some other sort of asynchronous event could do the
trick?
OK, enough discussion. Here is jump.ps. Have fun.
Chris Warth
ATT Bell Laboratories
Murray Hill NJ
ihnp4!ulysses!csw
-------------------- jump.ps --------------------
#!/usr/NeWS/bin/psh
%
% Christopher Warth
% ATT Bell Laboratories
% Murray Hill, NJ
% April 1987
%
/win framebuffer /new DefaultWindow send def
{
/FrameLabel (Chase me!) def
/EnterFrame {
gsave
ClientCanvas setcanvas
initgraphics
maxx random mul maxy random mul /move win send
grestore
} def
} win send
initgraphics
newpath clippath pathbbox
/maxy exch def
/maxx exch def
pop pop
100 100 200 200 win send
/map win sendgerolima@wdl1.UUCP (Mark Gerolimatos) (07/14/87)
I couldn't seem to get the window program to do anything! What did I
do wrong?
"For over a quarter of a century..."
Mark Gerolimatos
ARPA: gerolima@ford-wdl1.arpa "Let's take our neighbor for a ride!
UUCP: {sun,fortune}!wdl1!gerolima Would you like to go for a ride!?"
AT&T: (415) 852-4105 "Uuhhhh...no thanks."
USPS: c/o Ford Aerospace "No what?" "No, I wouldn't like to go."
3939 Fabian Way "Go Where!?" "Uuhh...for a ride..."
Palo Alto CA 94303 "A RIDE! Now that's a good idea!"
Mail Stop X20 -Frank and a friend, from Blue Velvettomlin@hc.DSPO.GOV (Bob Tomlinson) (07/17/87)
in article <6710002@wdl1.UUCP>, gerolima@wdl1.UUCP (Mark Gerolimatos) says: > I couldn't seem to get the window program to do anything! What did I > do wrong? There was a bug in the program posted. If I remember correctly the bug was that the second from the last line needed to read: 100 100 200 200 /reshape win send I think the /reshape was left out in what was posted. Agreed, fun program. -- bob -- Bob Tomlinson -- tomlin@hc.dspo.gov -- (505) 667-8495 Los Alamos National Laboratory -- MEE-10/Data Systems