cks@ziebmef.uucp (Chris Siebenmann) (03/19/89)
[hah. finally got around to commenting on this topic.] In article <6206@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: ... | Part of this is the Mac's clipboard. This makes integration of | artwork and text, and import of text, very easy. We in theory have the same | ability, but few people support the clipboard device (bad developers, bad! :-) | (That's just a joke!)). I can't comment on why everyone seems to ignore the clipboard, though I have a pretty good idea. I can tell you why ComicSetter doesn't use it, and it's very simple. There's no IFF routines that will write to the clipboard, and it's not at all obvious how to write them. You see, the clipboard requires you to put IFF data into it. Now IFF is a perfectly good structure for data; it's nicely recursive 'cause it's made up of things inside things (and so on..), includes a decent amount of error checking, and is very nice overall. However, each thing in an IFF data stream has to include its size (including the sizes of all sub-things inside it) ... at the beginning of itself. And the clipboard.device doesn't appear to support random seeking around to write data (when writing to a file, the IFF routines seek back to the start of a hunk and write the size once they know it). This makes it remarkably difficult to write a complicated recursive data structure out in IFF chunks to the clipboard, of course. You basically have to "write" it twice, once to find out the sizes of all the hunks, and the second time to do the real writing with the real sizes. Faced with this problem, we punted and decided that we didn't really need to support the clipboard after all (it didn't help that we were short for time). It only took me a couple of days to write the cut-and-paste code that didn't use the clipboard. Using the clipboard would have taken considerably longer, and we were short for time and code space. So (to turn this into a comp.sys.amiga.tech topic), having listened to my tale of woe, does anyone have any suggestions? Does the clipboard.device support random seeks after all (the documentation is remarkably opaque on this point)? Does anyone have a clever idea about how to do this, or nifty code? -- "Though you may disappear, you're not forgotten here And I will say to you, I will do what I can do" Chris Siebenmann uunet!{utgpu!moore,attcan!telly}!ziebmef!cks cks@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}cks
andy@cbmvax.UUCP (Andy Finkel) (03/22/89)
In article <1989Mar19.023257.20564@ziebmef.uucp> cks@ziebmef.UUCP (Chris Siebenmann) writes: >[hah. finally got around to commenting on this topic.] >sizes of all sub-things inside it) ... at the beginning of itself. And >the clipboard.device doesn't appear to support random seeking around >to write data (when writing to a file, the IFF routines seek back to >the start of a hunk and write the size once they know it). You're kidding me, right ? The CMD_WRITE of the clipboard device includes an io_Offset field, which you can change so you can write bytes anywhere in the clip. You can even extend the clip (padded with 0s) just by settng the io_Offset beyond the current clip size. The docs on CMD_WRITE come right out and say this, actually. You are right in that it doesn't say 'here's how to seek during Write.' But under both the READ and WRITE functions, the docs do mention the autoincrement properties of io_Offset, and how you can get normal sequential reads/writes by leaving the fields alone. (I also did an example program for AmigaMail a long time ago.) If you didn't understand you could have just asked someone. Time pressure can get to you sure, but when its so easy to ask the people who know! > So (to turn this into a comp.sys.amiga.tech topic), having listened >to my tale of woe, does anyone have any suggestions? Does the >clipboard.device support random seeks after all (the documentation is >remarkably opaque on this point)? Does anyone have a clever idea about >how to do this, or nifty code? io_Offset = seek_value; there you go :-) -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "The salesperson said this computer is the next best thing to sliced bread, but didn't say what to do about the crumbs in the disk drive." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
darin@nova.laic.uucp (Darin Johnson) (03/22/89)
In article <1989Mar19.023257.20564@ziebmef.uucp> cks@ziebmef.UUCP (Chris Siebenmann) writes: > I can't comment on why everyone seems to ignore the clipboard, though >I have a pretty good idea. I can tell you why ComicSetter doesn't use >it, and it's very simple. > > There's no IFF routines that will write to the clipboard, and it's >not at all obvious how to write them. Actually, I have seen a few routines that will write IFF to the clipboard. The latest of these was iffparse.library - although that won't be out of alpha/beta test for awhile (this is by Leo Schwab and Stuart Ferguson). When this is finished (and if Commodore picks it up) then I expect that IFF to clipboards will pick up. But until then, here is a simple minded kludge. Instead of writing out the data directly, use two passes. The first pass goes through all the motions of writing stuff out, but will not actually do IO. Instead, it keeps tracks of sizes of chunks. Whenever it figures out a size, it backpatches a table of chunk sizes. Then on the second pass, actually write out the data, looking up the correct sizes from the first pass. The first pass is non-trivial for generalized IFF, but assuming that you are outputing a known FORM, with a known nesting structure (ANIM's would be hard, ILBM's easier), it shouldn't be that hard - certainly lots easier than reading in IFF. Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) Can you "Spot the Looney"?
papa@pollux.usc.edu (Marco Papa) (03/22/89)
In article <6357@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >In article <1989Mar19.023257.20564@ziebmef.uucp> cks@ziebmef.UUCP (Chris Siebenmann) writes: >>[hah. finally got around to commenting on this topic.] >>sizes of all sub-things inside it) ... at the beginning of itself. And >>the clipboard.device doesn't appear to support random seeking around >>to write data (when writing to a file, the IFF routines seek back to >>the start of a hunk and write the size once they know it). > >You're kidding me, right ? The CMD_WRITE of the clipboard >device includes an io_Offset field, which you can change >so you can write bytes anywhere in the clip. You can even >extend the clip (padded with 0s) just by settng the io_Offset >beyond the current clip size. The docs on CMD_WRITE come >right out and say this, actually. [other details omitted] All true. I wonder how many people don't use the Clipboard just because of misinformation like the one Chris shows. >(I also did an example program for AmigaMail a long time ago.) I used the code in AmigaMail to add Clipboard support to A-Talk III. That code works like a champ. If the source is still around somewhere maybe it would be a good idea to post the clipboard source from AmigaMail on the net. --Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
peter@sugar.hackercorp.com (Peter da Silva) (03/22/89)
If the clipboard.device had a DOS handler associated with it (Clipboard:) everyone would use it. Suggestion for 1.4. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
shf@well.UUCP (Stuart H. Ferguson) (03/22/89)
+-- cks@ziebmef.UUCP (Chris Siebenmann) writes: | In article <6206@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: | | [...] but few people support the clipboard device (bad developers, bad! :-) | | (That's just a joke!)). | I can't comment on why everyone seems to ignore the clipboard, though | I have a pretty good idea. I can tell you why ComicSetter doesn't use | it, and it's very simple. | There's no IFF routines that will write to the clipboard, and it's | not at all obvious how to write them. This is one of the reasons that Leo and I just spent several months putting together the iffparse.library. Among other things, it lets you write IFF files to any stream using a simple calling syntax. One of the streams the library supports internally is the clipboard. So if you write routines to read and write IFF files with this library you get clipboard support essentially for free. | the clipboard.device doesn't appear to support random seeking around | to write data The clipboard does seek, it turns out. It's not a general purpose seek, but it's enough to write IFF files. There's an io_Offset field in the IOClipReq structure that can be positioned to a previous point in the clip. A seek by "n" bytes (forwards or backwards) is just: clipReq.io_Offset += n; followed by the read or write you want to do. Fortunately this is all transparent when using the iffparse library. Yes, this information is not well documented. | (when writing to a file, the IFF routines seek back to | the start of a hunk and write the size once they know it). The iffparse library can also write to non-seeking stream (such as pipes) by buffering the data in memory and blasting it out at the end. The stream just has to be flagged as non-seeking and this will happen transparently. | Faced with this problem, we punted and decided that we didn't really | need to support the clipboard after all (it didn't help that we were | short for time). It only took me a couple of days to write the | cut-and-paste code that didn't use the clipboard. Using the clipboard | would have taken considerably longer, and we were short for time and | code space. If this library can generate as much support as we hope (in the right places) this kind of story may never be heard again. Up til now it's been heard way too often. | Chris Siebenmann uunet!{utgpu!moore,attcan!telly}!ziebmef!cks -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (03/22/89)
In article <1989Mar19.023257.20564@ziebmef.uucp> cks@ziebmef.uucp (Chris Siebenmann) writes: > I can't comment on why everyone seems to ignore the clipboard, though >I have a pretty good idea. I can tell you why ComicSetter doesn't use >it, and it's very simple. > > There's no IFF routines that will write to the clipboard, and it's >not at all obvious how to write them. > Well, there are now (though admittedly this was of no use to you during ComicSetter's development). >And the clipboard.device doesn't appear to support random seeking around >to write data [ ... ] Guess what? It does. Just fiddle with the io_Offset field, and it works. We have internal clipboard support in our library. We do this and it works positively great. > This makes it remarkably difficult to write a complicated recursive >data structure out in IFF chunks to the clipboard, of course. You >basically have to "write" it twice, once to find out the sizes of all >the hunks, and the second time to do the real writing with the real >sizes. > Even with non-seeking streams, we can write a file in one pass. For non-seeking streams, we buffer it in memory until the whole file's written, then blast it out. Not exactly elegant, but it works. > So (to turn this into a comp.sys.amiga.tech topic), having listened >to my tale of woe, does anyone have any suggestions? [ ... ] >Does anyone have a clever idea about how to do this, or nifty code? > We have what I think is highly nifty code. Unfortunately, it's in Alpha test right now, and we're (Stu and I) kind of reticent about handing it out capriciously. We'll let y'all know when it's solidified. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
sgt@dukeac.UUCP (Stephen G. Tell) (03/23/89)
In article <1989Mar19.023257.20564@ziebmef.uucp> cks@ziebmef.UUCP (Chris Siebenmann) writes: ... > So (to turn this into a comp.sys.amiga.tech topic), having listened >to my tale of woe, does anyone have any suggestions? Does the >clipboard.device support random seeks after all (the documentation is >remarkably opaque on this point)? Does anyone have a clever idea about >how to do this, or nifty code? The clipboard device does support seeks; I asked the same question and answered it myself a while back by writing the code and finding that it works. What the world needs is a CLIP: handler that would handle a lot of the details. It looks easy for simple-minded clipboard use, where you always do the actual writing. The feature that lets you post a clip but not actually copy data unless someone wants it may be more difficult; I'm not sure how to fit this into a file-system paradigm. Steve -- Steve Tell: senior, Duke University school of Engineering (please hire me). Former Chief Engineer, Cable 13 / Duke Union Community Television. sgt@dukeac.ac.duke.edu; !mcnc!ecsgate!dukeac!sgt
mjw@cs.cmu.edu (Michael Witbrock) (03/30/89)
> *Excerpts from ext.nn.comp.sys.amiga.tech: 19-Mar-89 Supporting the clipboard* > *(R.. Chris Siebenmann@ziebmef (2450)* > There's no IFF routines that will write to the clipboard, and it's > not at all obvious how to write them. > > You see, the clipboard requires you to put IFF data into it. Now IFF > is a perfectly good structure for data; it's nicely recursive 'cause > it's made up of things inside things (and so on..), includes a decent > amount of error checking, and is very nice overall. However, each > thing in an IFF data stream has to include its size (including the > sizes of all sub-things inside it) ... at the beginning of itself. And > the clipboard.device doesn't appear to support random seeking around > to write data (when writing to a file, the IFF routines seek back to > the start of a hunk and write the size once they know it). > This makes it remarkably difficult to write a complicated recursive > data structure out in IFF chunks to the clipboard, of course. You > basically have to "write" it twice, once to find out the sizes of all > the hunks, and the second time to do the real writing with the real > sizes. > Faced with this problem, we punted I had a similar problem with recursive screen output. It's actually not too difficult to do at all, providing that your output routines are recursive. for each output routine foo(bar baz) add two params DoOutput (boolean) and Size (int) and have it return the size of the object it writes out. i.e. int foo(bar baz DoOutput Size) repleace each call to foo with two size= foo (bar, baz, FALSE, 0) if (size!= foo(bar,baz,TRUE,size) { /*SOMETHING BAD HAPPENED*/} replace each output statement in foo by if (DoOutput){ output statement } returnedsize += size of output object; Making these changes is guaranteed correct for code without side effects (which suck in recursive (or other) code anyhow). It is very easy and fast to do, and it adds hardly any extra code. It has a less than 100% overhead on the original operation. Maybe we can have our clipboards supported now. Please..... michael Michael J Witbrock / School of Computer Science / Carnegie Mellon University /\ Pittsburgh PA 15213-3890 U.S.A / \ /* sorry if this is difficult to read, it was written with messages, which is proportional width*/
scott@applix.UUCP (Scott Evernden) (03/30/89)
In article <gYAE33y00hke00oGlE@cs.cmu.edu> mjw@cs.cmu.edu (Michael Witbrock) writes: >> *Excerpts from ext.nn.comp.sys.amiga.tech: R.. Chris Siebenmann@ziebmef > >> There's no IFF routines that will write to the clipboard, and it's >> not at all obvious how to write them. >> >> You see, the clipboard requires you to put IFF data into it. I meant to ask this before. Where in the manuals does it say that the clipboard _requires_ you put IFF data into it? I'd like to read more, and I just don't recall stumbling across this rule. -scott