Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!apollo!mageau
From: mageau@apollo.uucp (Paul Mageau)
Newsgroups: comp.sys.amiga
Subject: Re: to clipboard or not to clipboard(long)
Message-ID: <31f3b208.7d27@apollo.uucp>
Date: Wed, 17-Dec-86 12:16:43 EST
Article-I.D.: apollo.31f3b208.7d27
Posted: Wed Dec 17 12:16:43 1986
Date-Received: Thu, 18-Dec-86 02:45:40 EST
References: <1878@jade.BERKELEY.EDU> <7737@topaz.RUTGERS.EDU> <1923@jade.BERKELEY.EDU> <1515@ulysses.UUCP>
Organization: Apollo Computer, Chelmsford, Mass.
Lines: 50

>Yeah, I've thought of that too, but unfortunately, you can't do
>SunTools or the Apollo DisplayManager on an Amiga. Once text is 
>rendered into a window it loses it's context as "text" and becomes 
>straight bitmap. Now, you could select a region from another
>window's bitmap, but how do you translate it to ASCII? - not
>trivial - once you had that it would be fairly easy though, just
>dump it into another window's controlling process's input stream.


Instead of throwing away the text, just save it in a temporary file,
much the what the Apollo Display Manager does. What this allows you to do 
is to scroll back in time, by scrolling thru this ASCII 'image' of your
complete history of the text that enters your window( Apollo call this a 
transciprt pad). This file is used by the diaplsy manager when a window must be 
refreshed or new info is to be displayed(form either scrolling around a file
or outputing new stuff). This notion of a window being a viewport over a file
is no different than the way the AmigaDOS 'ED' command works.
THE POINT IS THAT REGULAR WINDOWS(I.E CLI TYPE) DO NOT HAVE TO BE HANDLED
DIFFERENTLY THAN EDIT WINDOWS.

Can a similar thing be done for the Amiga ?

I think so, but since we are not talking about a virtual memory machines with large disks,
some comprimises will probably have to be made.

The transcipt pad(s) can get very large, which means you can easily run out of disk space
and physical memory. So, you may only want to buffer a few pages of the pad(s) in main memory 
and have the disk hold the remainder(have the upper limit programmable). At some point, the
history become less useful so reducing the amount of history you care to save should be OK.

One process should handle all of the input and output(i.e the display manager process). Each
process will receive it input from this process and send all its output intended for standard
output to this process, which will then act on the sender's window accordingly.

I don't pretend to think that this is a small undertaking or that a SUN or similar envorinment
would also be desirable(maybe some hybrid of Sun and Apollo is best ?). What little spare time I
have I would like to try to do something like this.  Anyone else out there interested in a joint
project or just kicking a few ideas for the architecture around ????



Paul Mageau
Phone 1-617-256-6600 (work)                                      
      1-617-597-5260 (home)


DISCLAIMER : THIS IN NO WAY HAS TO DO WITH ANY CURRENTLY ONGOING WORK OR FUTURE WORK BEING DONE 
             BY APOLLO COMPUTERS. INC. THE ABOVE MENTIONED IDEAS ARE MY OWN(FOR WHAT THEIR WORTH).
             APOLLO COMPUTER IN NO WAY BENEFITS FROM ANY WORK THAT TRANSPIRES AS A RESULT OF THIS
             MESSAGE.