swan@jolnet.ORPK.IL.US (Joel Swan) (10/04/89)
In article <PORTUESI.89Oct2102409@tweezers.esd.sgi.com> portuesi@sgi.com (Michael Portuesi) writes: :In article <2057@leah.Albany.Edu> wfh58@leah.Albany.Edu (William F. Hammond) writes: : : In article <1627@jolnet.ORPK.IL.US>, swan@jolnet.ORPK.IL.US (Joel Swan) writes: : : > IF IT DOESN'T SUPPORT CLIPBOARD BUT SHOULD- _I WON'T BUY IT_!! : > : I agree. Please note that an editor that uses the clipboard does not : need to have a multi-windowing facility (i.e., does not need to reinvent : the wheel). You can open a document, take a clip, close that document, : and go to another to insert the clip. Editors that eliminate unnecessary : features are smaller. : : :Sorry, but I would list multi-windowing as a basic capability of any :screen editor, whether it divides itself into panes, opens separate :intuition windows, or can be made resident so that you can run :multiple copies of it at the same time. I think what William is saying is that he doesn't think multiple windows are needed to perform the function of the clipboard, not that all multiple windows are uneeded. To this I agree, they aren't NEEDED, but are still useful. (needed to clip that is). I like my multi-windows. : Note that under WorkBench 1.3 the clips don't have to be put in : devs:clipboards. Perhaps the fact that this was true in the past explains : why some developers opted away from the clipboard facility. : : :I was under the impression that developers opted away from the :Clipboard because it was poorly documented, difficult to support, its :functionality could be provided with the ram disk, and its usefulness :is limited by external factors mentioned below. : :This is not intended to be a flame against the Clipboard. I would :like to see Clipboard support in all programs myself. Though if the :Clipboard is to be truly successful, the following things must happen: ^^^^^^^^^^^^^^^^ Truely sucessful for what? We are talking about text processors here, not graphics/music programs. Therefore.... : * There needs to be more IFF standards for things such as 2D : structured drawings and multifont text (Yes, I know about : FTXT, but how many applications actually use it?). (This is a self prophesying statement. "I know there is one, but we won't/don't use it.") : * There needs to be system support for handling all IFF : formats (in the form of an iffparse.library, followed by : separate libraries for handling each specific IFF type) that : applications can depend on using. whereas the above would be very nice, it is no excuse to ignore the standard we do have, that is, text clipboards. : :The big reason the Mac clipboard is useful is that not only does every :application support it, there are standard definitions for text, :bitmaps and drawings, along with system ROM support for handling these :formats. The Amiga has standards for some of these formats, but not :all of the useful ones, plus no standard system support for any of :these formats. : :Exchanging information between applications is no good unless the :applications know what to do with it. People who are wondering why :applications don't support the Clipboard are only looking at part of :the overall picture. Wrong. People who wonder why applications don't support the Clipboard see some applications who use it, and get tired of seeing other programs ignore it. We AGREE that a full standard for all IFF formats should be plainly laid out and explained BUT... that does not excuse non-support of the one standard that IS there, and is used by a few. Who's to say a new, complete IFF clipboard would be used at all based on the support it has received in the past. I certainly hope the clipboard does become a useful, full-fledged, supported part of the Amiga in the future. It would really make the Amiga come a long way. : --M :__ :\/ Michael Portuesi Silicon Graphics Computer Systems, Inc. : portuesi@SGI.COM : :"The best length for television programs is either 30 seconds or 8 :hours." David Byrne Joel E. Swan (Our system is broke. Sorry, no .sig file)