mwm@eris.UUCP (12/10/86)
While at the FAUG meeting last night, I asked a developer if his new product would talk to the clipboard. The answer was "it will handle any file with a DOS name. You can use ram:, why bother with the clipboard?" Seeing that the product in question has doesn't currently - and probably won't in the future - deal with IFF format objects, this makes some sense. Why add code to handle them (as required by the clipboard), plus code to deal with the clipboard.device driver, when the same functionality already exists? I'd been thinking about adding access to the clipboard to mg. But this makes it seem like a bad idea. The general rule would seem to be: "If it deals with IFF format files, make it deal with the clipboard. Otherwise, don't bother." Anyone got any comments? Why should something like emacs use the clipboard, when you can insert any DOS file? Can someone see what good it would do? Thanx, <mike
eric@topaz.UUCP (12/12/86)
>I'd been thinking about adding access to the clipboard to mg. But this >makes it seem like a bad idea. The general rule would seem to be: "If >it deals with IFF format files, make it deal with the clipboard. >Otherwise, don't bother." > >Anyone got any comments? Why should something like emacs use the >clipboard, when you can insert any DOS file? Can someone see what good >it would do? > > Thanx, > <mike Sure I can: picture the scenario: A person is running his favorite terminal program, the terminal progam supports cuts and pastes from the clipboard... fire up your editor which supports the clipboard as well. Now the user can paste *part* of a file to the clipboard and switch to the terminal program to paste it in (I assume the terminal program will be smart enough to encapsulate the data in some communication protocol). The person can also grab part of his session and paste it to the clipboard, edit it, paste it back and send it back - maybe even compile it if it was code. But... #begin MILD_FLAME I must say that after working with the clipboard, it has problems. The intentions I'm sure were good, but it's obvious that not enough time was put into it. It's a device, and it's IFF (actually, it's anything you want, but for the purpose of being able to make assumptions about what's there, you make it IFF - so your application has to know all about the IFF you care about)... The clipboard is not integrated into the entire Amiga environment like the Mac's is (or maybe even the ST?) which seriously limits it and may be one of the reasons why no one has bothered to deal with it: If a user can't see it, why should he bother using it (but we know better, right?)... Now a real WYSIWYG editor or DeskTop Publisher should probably support the clipboard - but again, it could get by without it: IFF is already an interchange standard - couple that with a file system and the only advantage of the clipboard is for management of internal buffers for IFF data. mg already has buffers... #end MILD_FLAME So, sure mg will get along fine without the clipboard - I would consider it an extra feature to do when you have nothing else left to do with it :-) In the meantime, you can always use an internal mg buffer, put what you want into it, and write it to a file and let the other applications bother with reading in your text from a regular file. And the same goes for anything mg needs to read in... Eric Whew! - I never knew I had so much to say about the clipboard! Please keep in mind that others may disagree with me - this is my personal opinion, but I have worked with the durned thing... I'd like to hear from someone who could defend the clipboard - I think it's concept is good, but it's execution on the Amiga falls short. -- ARPA: LAVITSKY@RUTGERS or LAVITSKY@RED.RUTGERS.EDU UUCP: ...topaz!eric ...hplabs!well!lavitsky ...ulysses!eric
mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (12/13/86)
In article <7737@topaz.RUTGERS.EDU> eric@topaz.RUTGERS.EDU (Eric Lavitsky) writes: >So, sure mg will get along fine without the clipboard - I would >consider it an extra feature to do when you have nothing else left to >do with it :-) In the meantime, you can always use an internal mg >buffer, put what you want into it, and write it to a file and let the >other applications bother with reading in your text from a regular >file. And the same goes for anything mg needs to read in... Actually, when I get around to adding drag-selecting regions to mg, I'll probably add "write-region" so you can do "down - move - up" and type a file name to have the selected text saved to a file. Not much harder than using the clipboard. Thanx for the input, though. Maybe I'll ask the X people if they consider the system shelf (read: clipboard) important. And I just had a thought (rare moment, that!): how about a utility that sits on the input stream, watching for certain flavors of mouse activities to twiddle the stream? Say, left-amiga-mouse up/drag/down to select stuff, and right-amiga-mouse-click to insert the text into the input stream? Not sure it's possible, but it'd give me what I miss most from suntools (the ability to put arbitrary text on the shelf, then dump it back into another window). <mike
eric@ulysses.UUCP (Eric Lavitsky) (12/15/86)
>And I just had a thought (rare moment, that!): how about a utility >that sits on the input stream, watching for certain flavors of mouse >activities to twiddle the stream? Say, left-amiga-mouse up/drag/down >to select stuff, and right-amiga-mouse-click to insert the text into >the input stream? Not sure it's possible, but it'd give me what I miss >most from suntools (the ability to put arbitrary text on the shelf, >then dump it back into another window). > > <mike 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. Now, you could do this within your own editor, and even perhaps from your editor to another process (which could be very useful), but not necesarily from another process to your editor. Of course, if it were possible to associate input buffers with any window, and a method for getting at another window's input buffer, one could do this on the Workbench, in fact not only would you be able to cut & paste text (gee, this would make the clipboard much more useful as well), but anything in the input stream (mouse movements, clicks etc.) though you should be able to selectively mask out events if you don't want them. There is no standard or defined way of doing all this (perhaps you'd like to cook one up? - without Amiga sources it would be tough). But that would mean heavily re-working the Workbench, something I'm sure C-Amiga doesn't have time for right now :-(. If anybody has a better answer (or if I've placed sneaker in mouth), I'd like to hear it. Gee Mike, do you get the feeling that I'm always trying to rain on your parade? :-) Eric -- ARPA: Lavitsky@RED.RUTGERS.EDU UUCP: ...ulysses!eric ...caip!topaz!eric ...hplabs!well!lavitsky
gary@well.UUCP (Gary J. Albert) (12/16/86)
In article <1878@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: > > ...... The general rule would seem to be: "If > it deals with IFF format files, make it deal with the clipboard. > Otherwise, don't bother." > > Anyone got any comments? Why should something like emacs use the > clipboard, when you can insert any DOS file? Can someone see what good > it would do? > > Thanx, > <mike The one reason I can see for having emacs talk to the clipboard is if you planned on using the data from emacs in another program that was expecting it. Say for example you wanted to create a document containing both text and graphics and you had some word processor or document preperation program that could handle both. It would seem natural for this tool to expect it's input data in IFF format. Now I realize that whatever this other program is would probably have the provision of creating the text itself, but I know how hard it is to give up the editor you like the most. If emacs could output to the clipboard (or even just a file) in IFF format you could then take this output and read it into this other, un-named, tool and you would be all set. I don't know how likely this scenario is but it seems reasonable to me. ...!well!gary Gary Albert
mageau@apollo.uucp (Paul Mageau) (12/17/86)
>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.
wagner@utcs.UUCP (12/20/86)
In article <1878@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: > >I'd been thinking about adding access to the clipboard to mg. But this >makes it seem like a bad idea. The general rule would seem to be: "If >it deals with IFF format files, make it deal with the clipboard. >Otherwise, don't bother." Well, I'm not sure that this is right. I read all the follow-ups to this article, and I think there is at least one thing that people missed. The clipboard is a single, fixed place. You don't have to put up a requester, and interact with the user. I have to admit that, if your application is not using IFF and 'into' making provision for interchange, it's a pain to use the clipboard. However, there are advantages for doing so. Clipping the words to a tune out of a music program, and pasting them into a word processor is a useful thing. Now, perhaps, it can be argued that the music processor should have provided this ability for flat files as well, but I would argue that there is no reason for the music program to provide the same functionality twice. The clipboard is there...one should be able to rely on it's use by other programs that want to interchange with each other. Perhaps it would help if there were tools (are there already?) to take flat text and put it into the clipboard (and vice versa). Ramble, ramble......I've been away for a week, and there are 350+ articles in comp.sys.amiga to read. Groan! Michael