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.