#!/usr/NeWS/bin/psh % From: csw@ulysses.homer.nj.att.com (Chris Warth) % Subject: changes to psterm (and a fun program too) % Date: 7 Jul 87 20:12:12 GMT % Organization: AT&T Bell Laboratories, Murray Hill % % % 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 -------------------- % % 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 /reshape win send /map win send