portuesi@tweezers.esd.sgi.com (Michael Portuesi) (10/02/89)
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. You see, it's very convenient to have multiple windows open, because you can see more than one file at the same time, or different parts of the same file at the same time. Putting in Clipboard support isn't going to replace this functionality. 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: * 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?). * 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. 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. --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
peter@sugar.hackercorp.com (Peter da Silva) (10/04/89)
In article <PORTUESI.89Oct2102409@tweezers.esd.sgi.com>, portuesi@tweezers.esd.sgi.com (Michael Portuesi) writes: > 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: * It must be no harder to use the clipboard than it is to use a file. The easiest way to do this is to provide a CLIPBOARD: handler. That way you could open CLIPBOARD:0, write stuff, and close it with no more difficulty than you have now creating a file in RAM:. For 1.4. Pretty please? -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>
nsw@cbnewsm.ATT.COM (Neil Weinstock) (10/05/89)
In article <4272@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: [ ... ] Re: clipboard: > * It must be no harder to use the clipboard than it is to use > a file. The easiest way to do this is to provide a CLIPBOARD: > handler. That way you could open CLIPBOARD:0, write stuff, > and close it with no more difficulty than you have now creating > a file in RAM:. I'll bite. How is this any different from using RAM in the first place? What if you were to define a standard subdirectory, RAM:clipboard (maybe do assign clipboard: RAM:clipboard by default), and a standard name for the default "current" clipboard entry, and leave it at that? This would involve little or no work in the OS, and only minimal work on the part of the applications, since all they'd have to do is consider all clipboard-like operations to be file operations hard-wired to a particular file in RAM:. In the abstract sense, how is a clipboard any different from a file in a dynamically resizable RAM disk? ________________ __________________ ____________________________ //// \\// \\// \\\\ \\\\ Neil Weinstock //\\ att!cord!nsw or //\\ "Oh dear, now I shall have //// //// AT&T Bell Labs \\// nsw@cord.att.com \\// to create more Martians." \\\\ \\\\________________//\\__________________//\\____________________________////
rosenber@ra.abo.fi (Robin Rosenberg INF) (10/05/89)
In article <4272@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: > In article <PORTUESI.89Oct2102409@tweezers.esd.sgi.com>, portuesi@tweezers.esd.sgi.com (Michael Portuesi) writes: > > 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: > > * It must be no harder to use the clipboard than it is to use > a file. The easiest way to do this is to provide a CLIPBOARD: > handler. That way you could open CLIPBOARD:0, write stuff, > and close it with no more difficulty than you have now creating > a file in RAM:. MHO: It is no harder than writing/reading files, really. It looks different and it's more flexible. For simple clipboard access the correspondence is like this. fopen() --> OpenDevice(), set id and io_Offset to zero fwrite() --> set data and length, CMD_WRITE fread() --> set data and length, CMD_READ, check io_actual fseek() --> fill in the io_Offset field before read or write fclose() --> CMD_UPDATE, CloseDevice() Wha *IS* nasty is reading the thing. This is because one cannot know what is in the clip other than it is an IFF file. The special case is a CAT with id 'CLIP' or id ' ', (the docs are ambigous on this). This kind of clip is for representing alternative forms of the data, Lets say a spreatsheet supports the clipboard (Maxiplan does not, grrrrr...), If it's correct and the authors have understood the philosophy of the clipboard the would write a clipfile like this CAT CLIP FORMSPSH - 'SPSH' -> spreadsheet data whatever format the spreadsheet preferes it's data in FORMFTXT - 'FTXT' -> Formattet text. Can be simple text if there is no need for formatting it. FORMILBM - 'ILBM' -> Graphical representation (seems a little superflous in this case. Now switch to a word processor and select 'paste'. The program sees that the clip has alternative representations so it scans the clip for a representation it understands and processes it. The rest is skipped since it is other representations of the same thing. I know of no programs that handles the clipboard correctly. Most assume that the clipboard contains a FORM-FTXT, otherwise it chokes. I think this must be annoying for developers since thay cannot implement the clipboard fulle (in most cases) without being incompatible with other programs. What is needed is powerful and easy to use routines for manipulating iff-files in a correct and consistent manner. C-A has only provided code and examples the simple cases. The guidelines are very fuzzy. > For 1.4. Pretty please? Simple routines for the simple cases and more advanced routines for the nasty ones. "Simple things should be simple and complex things should be possible" should be the rule. Another question: WIll there be a format for structured drawings in 1.4? ---------- Robin Rosenberg
peter@sugar.hackercorp.com (Peter da Silva) (10/05/89)
In article <4998@cbnewsm.ATT.COM>, nsw@cbnewsm.ATT.COM (Neil Weinstock) writes: > In article <4272@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > > * It must be no harder to use the clipboard than it is to use > > a file. The easiest way to do this is to provide a CLIPBOARD: > > handler. > I'll bite. How is this any different from using RAM in the first place? When you fill memory, the clipboard will overflow to a file in CLIP: called CLIP:0 (for the default clipboard), CLIP:1, etc. So you can clip things without having to worry about running out of RAM, just by putting CLIP: on magnetic media. Secondly, a CLIPBOARD: handler for the clipboard device would allow you to easily interoperate with programs that already use the clipboard. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>
peter@sugar.hackercorp.com (Peter da Silva) (10/05/89)
In article <156@ra.abo.fi>, rosenber@ra.abo.fi (Robin Rosenberg INF) writes: > It is no harder than writing/reading files, really. It looks different So you can't just use your simple IFF reader/writer routines to do it. And there's no good reason for this. > and it's more flexible. Huh? What can you do with the clipboard you can't do with a file? -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>
cmcmanis%pepper@Sun.COM (Chuck McManis) (10/06/89)
>In article <4272@sugar.hackercorp.com> (Peter da Silva) writes (I think): >> * It must be no harder to use the clipboard than it is to use >> a file. ... That way you could open CLIPBOARD:0, write stuff, >> and close it with no more difficulty than you have now creating >> a file in RAM:. [Peter: See Andy Finkel's clip.handler on the DevCon II disks. It sets up the device CLIPS: which is almost like a file] In article <4998@cbnewsm.ATT.COM> (Neil Weinstock) responds: >I'll bite. How is this any different from using RAM in the first place? [A little context for a comment :-)] The Clipboard started out with a vision as far as I can tell. And that vision was "Universal place to put objects of indeterminate structure." The only flaw in the vision that I could see was that it counted on people being able to understand IFF and that was (and is) a big bottleneck for a lot of people. Back at the earliest DevCon's and talks at BADGE the vision was "... you write this thing onto the clipboard in a form that application X understands, and when you paste it, it appears in a form that application Y understands." So if you clipped a SMUS track from a music program and pasted it into a music notator it would come out as sheet music. I'm not sure what would happen if it was pasted to NotePad. (Probably appear as a bunch-o-notes. :-)) This differs significantly from RAM: in that the files there are free form and if they aren't text your application may not understand them, and may not _know_ that it doesn't understand them. It's a good vision and the iff.library will help because it specifically allows you to talk to the clipboard (and avoid the problems of seeking backwards and such.) What it doesn't provide is the other half of what is required which is "Given a FORM xxxx on the clipboard, and that I understand FORM yyyy, find me a conversion routine that will translate from one to the other." For some, like 8SVX -> ILBM it should be pretty easy (the PLPLOT stuff would do it nicely) but others like ILBM->8SVX or ANIM->FTXT are less easily specified. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "If I were driving a Macintosh, I'd have to stop before I could turn the wheel."
shf@well.UUCP (Stuart H. Ferguson) (10/13/89)
+-- nsw@cbnewsm.ATT.COM (Neil Weinstock) writes: | In article <4272@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: | [ ... ] | Re: clipboard: | > * It must be no harder to use the clipboard than it is to use | > a file. The easiest way to do this is to provide a CLIPBOARD: | > handler. That way you could open CLIPBOARD:0, write stuff, | I'll bite. How is this any different from using RAM in the first place? | What if you were to define a standard subdirectory, RAM:clipboard (maybe do | assign clipboard: RAM:clipboard | by default), and a standard name for the default "current" clipboard entry, | and leave it at that? | In the abstract sense, how is a clipboard any different from a file in a | dynamically resizable RAM disk? There are several differences. 1. The clipboard device deals differently with multiple simultanious access than a ramdisk. A write to the clipboard will always be sucessful, whereas an attempt to write to RAM:clipboard/0 might fail if the file was being accessed by another application. This is generally not a problem since the clipboard is used mostly interactively anyway, but it's something to think about. 2. (and this is more important) The clipboard device has a defered post mechanism, so that a provider of the clip need not actually write the clip to the clipboard unless there is a consumer out there who wants it. This is done with messages. For example, suppose some application with pictures in some internal format uses "cut" and "paste" commands to move the picture around internally. It may be innefficient to convert to ILBM format from the internal format every time the user specifies a "cut," so the application uses it's own internal fast cut and paste buffer. But what if the user wants to "paste" to another application? The application can, every time the user "cuts" an image, inform the clipboard that is has something to post. If the paste is internal, it can use the fast paste buffer. If the paste is into another application, the other application will try to read the clipboard. The clipboard says, "Hey wait! I don't have the data yet!," blocks the read attempt and sends a message to the source application to satisfy the post. The source application engages its engines to convert the internal format to ILBM, and writes that to the clipboard. When it has the data, the clipboard now completes the operation started earlier and gives the data to the destination application. Notice that with the above scenario, anyone reading the clipboard would see it as if the data were already there, when in fact the data wasn't there until after it was asked for. Do that with a file. 3. By being a distinct device, the clipboard defines an interface that can be extended. The satisfy/post mechanism is only one such enhancement. To dumb tools it can look like a file and they won't be any the wiser. To clever programs, it can have much more elaborate behavior and be more like a clearinghouse for data transfer, or IPC with a device-like interface. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (ferguson@metaphor.com)
shf@well.UUCP (Stuart H. Ferguson) (10/13/89)
+-- rosenber@ra.abo.fi (Robin Rosenberg INF) writes: | [ writing the clipboard is like an ordinary file ... ] | Wha *IS* nasty is reading the thing. This is because one cannot know what is | in the clip other than it is an IFF file. I don't understand. How does this make it *harder* than reading a file? Files can be anything; at least you know the clipboard is IFF. | The special case is a CAT with id 'CLIP' or id ' ', (the docs are ambigous | on this). The docs (RKM: Libraries and Devices) say specifically that this is a CAT with identifier 'CLIP', not ' '. Perhaps you were looking at the output of a particular program...? | This kind of clip is for representing alternative forms of the data, | Lets say a spreatsheet supports the clipboard (Maxiplan does not, grrrrr...), | If it's correct and the authors have understood the philosophy of the | clipboard the would write a clipfile like this | | CAT CLIP | FORMSPSH - 'SPSH' -> spreadsheet data | whatever format the spreadsheet preferes it's data in | FORMFTXT - 'FTXT' -> Formattet text. Can be simple text | if there is no need for formatting it. | FORMILBM - 'ILBM' -> Graphical representation (seems a little | superflous in this case. | | Now switch to a word processor and select 'paste'. The program sees that the | clip has alternative representations so it scans the clip for a representation | it understands and processes it. The rest is skipped since it is other | representations of the same thing. I quoted this whole example because it's exactly correct. CAT CLIP is designed to allow data to be cut and pasted between different applications by letting the destination application find the kind of data it's interested in among the different interpretations. This can be a beautiful thing when it's done right (or done at all, for that matter). Let's say you have two spreadsheets and a text document open at the same time. You select some interesting part of the spreadsheet and "Copy" it to the clipboard. Now you go to the other spreadsheet and "Paste" the data there. You get all the data and the formulas and formatting and everything that makes this spreadsheet data. Now -- WITHOUT DOING ANYTHING ELSE -- you paste the SAME clip into the document. Now you get the same data but in text form, perhaps formatted into columns with tabs. The formulas and everything are gone, but this is exactly what you want for a document. | > For 1.4. Pretty please? | Simple routines for the simple cases and more advanced routines for the nasty | ones. "Simple things should be simple and complex things should be possible" | should be the rule. Working on it. | Another question: WIll there be a format for structured drawings in 1.4? If you've got ideas, do it, but don't hold your breath waiting for Commodore to define it. Perhaps the "PLT:" people would like to design such a thing. Just don't make it HPGL-like, please. :-) -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (ferguson@metaphor.com)
shf@well.UUCP (Stuart H. Ferguson) (10/13/89)
+-- cmcmanis@sun.UUCP (Chuck McManis) writes: [ about the ideas behind the clipboard... ] | the vision was "... you write this thing onto the clipboard in a form | that application X understands, and when you paste it, it appears in a | form that application Y understands." So if you clipped a SMUS track | from a music program and pasted it into a music notator it would come | out as sheet music. [ ... ] | what is required which is "Given a FORM xxxx on the clipboard, and that | I understand FORM yyyy, find me a conversion routine that will translate from | one to the other." For some, like 8SVX -> ILBM it should be pretty easy | (the PLPLOT stuff would do it nicely) but others like ILBM->8SVX or | ANIM->FTXT are less easily specified. I think you're a little confused here, Chuck. The clipboard was never about translating between FORM's. It actually makes almost no sense to try to do this since almost by definition a given FORM-type is the canonical format for a piece of data of a given type. What you missed, I think, was the concept of the CAT CLIP, which is how the clipboard provides for communication between programs that deal with different types of data. There's another posting about this that goes into more detail so I won't repeat it all here, but the basic idea is that the source of the data provides the same data object in as many varient forms as makes sense, and the clients that read this data will strip out the FORM's they understand and ignore those they don't. If the clipboard contains no FORM's of a type that you understand, then you can't paste that clip. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (ferguson@metaphor.com)