Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!think.com!mintaka!geech.gnu.ai.mit.edu!rjc From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Message-ID: <1991Jun26.225018.18846@mintaka.lcs.mit.edu> Date: 26 Jun 91 22:50:18 GMT References: <14248@pasteur.Berkeley.EDU> <1991Jun24.230638.7865@mintaka.lcs.mit.edu> <1991Jun26.122255.24634@wehi.dn.mu.oz> Sender: news@mintaka.lcs.mit.edu Organization: The Internet Lines: 86 In article <1991Jun26.122255.24634@wehi.dn.mu.oz> baxter_a@wehi.dn.mu.oz writes: >In article <1991Jun24.230638.7865@mintaka.lcs.mit.edu>, rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >> No, the design isn't inferior, it's the implementation that is. >> The Amiga clipboard.device is very robust and can take any type of >> data. If developers don't support it, that doesn't make the clipboard.device >> itself inferior, it makes the implementation inferior in practice. >> > >The clipboard is buggier than a dingo in a shanty town. Just try using >it in low memory conditions with CLIPS: assigned to a disk (better not >make it your hard disk). The whole OS has always had problems in low-memory conditions, this has been fixed in 2.0. It's not a problem local to the clipboard. In 1.3 try eating up almost all memory, then get intuition to put up a few requesters..boom guru. (usually FreeListCorrupt) >> Your example is flawed. The clipboard.device has been in the OS >> since the beginning and nothing had to be rewritten. A more accurate example >> would be if Apple made some interface routines for the AMD and developers >> didn't use it. That doesn't make the AMD itself inferior to the Amiga >> chipset, it makes the implementation of it's use inferior. >> > >It hasn't really. C= didn't write the parsing routines. Their _own_ >programs didn't support it. The Notepad does. >> Sheesh, what a nitpick. It takes about 12 lines of code to do a >> Cut() to the clipboard. If a developer is so lazy that he can't >> implement a very easy routine like this than he needs to pack up his >> computer and head for the IBM. Apple's problem is they like to put >> EVERYTHING in the OS. Hell, they may as well incorperate Microsoft >> Word into the OS with a single function cal{, void Word(char *path); >> Just so you know, 2.0's iffparse.library includes 2 calls, >> OpenClipBoard and CloseClipBoard which aid the programmer who is too lazy >> to set up an IORequest. >> > >Crap. The C= bits and pieces from the Fish disks are much greater than >12 lines, and then you need to get the data into some sort of >interchange format. I was estimating the amount of code needed to set up an IORequest. Converting it to a format is different, that's what 2.0 IFFParse is for. > >> So we have concluded >> 1) The Amiga clipboard.device is totally open in design and supports >> the same amount of data that the Mac's does. (contrary to >> Marc's uninformed statement that it supports ASCII only) > >It is used for ascii only. Name one graphics program that cuts to >clipboard. (I'd really like to know). Snap. >> 2) The clipboard.device never took off because Amiga developers choose >> not to support the clipboard (and some of them don't even support the >> Amiga OS, e.g. bypass it and go to the hardware, etc) There is nothing >> Commodore can do about this, the users must demand an end to this >> and not buy products that break the rules. >> > >C= didn't support it. Writing for it is a _real_ pain. Especially >debugging, when there isn't anything to view your clips with. Try using notepad. > >> When you talk about the Amiga's clipboard, you must distinguish between >> the clipboard _itself_ and how developers choose to use it. >> > >And you must distinguish what C= could do with it from what they have. Try looking at 2.0. >Regards Alan -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /