Path: utzoo!utgpu!water!watmath!clyde!burl!codas!usfvax2!jc3b21!fgd3 From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe) Newsgroups: comp.sys.amiga Subject: Re: Ban the Cloud! (plus sugg. for Workbench) Summary: More about "magic windows" Keywords: Workbench Message-ID: <357@jc3b21.UUCP> Date: 1 Apr 88 05:51:12 GMT References: <318@jc3b21.UUCP> <832@sandino.quintus.UUCP> Organization: St. Petersburg Jr. College, FL Lines: 102 This continues a discussion of Peter Schachte's suggestion that Workbench be modified to create what he called "magic windows" for handling redirection of standard input and standard output. > Do you mean complicated to the user, or complicated to implement. I meant complicated to implement. I was concerned about the problem of knowing when to open the window. Your approach of creating a standard output file handle for the program and having the device open a window for the file only if data is written to it sounds good. > > I don't like the idea of creating hidden files, though. > > The reason I want the file to be hidden is that I want it to go away > cleanly unless the user does something with it explicitly. This is > important to my model of how it will be used. The idea is that these > magic windows represent (present) the output of a task. This data > could be put into a file (redirection), or sent to another task > (piping). But whatever I do, nothing I don't know about and haven't > asked for will be left around when I close the window. > > Maybe I've misunderstood you. I did expect that the data would be > stored in some ordinary file somewhere. The MAGIC: thing is just a way > to make sure that a window views the file, and the file is deleted when > the window is closed. That's all. The file isn't "hidden" from the OS. OK. That answers my objection. The file really exists, you don't have anything lying around on disk that the OS doesn't know about. Now I have another problem: what do you do if the system crashes before the file is deleted? If the file is confined to RAM: we wouldn't have a problem. Another option which might be simpler would be to simply write the data to a buffer in memory. The device could allocate the buffer and pass a file handle to the program. If the program used the file handle the device would open the window and display the buffer contents. Then the user could save the buffer to a file by a menu option if he wanted. When the program is through with the buffer is simply frees the memory. Nothing is left around unless the user asked that it be kept. What do you think about using a memory buffer instead of a disk file? If the program has a lot of output that approach would tie up a lot of memory. On the other hand, I have 2.5 MB of RAM and 880 KB + 880 KB + 440 KB (2.2 MB) of disk space. It would be a pain to have to swap floppies just because some background process was still writing to standard output. > ... Ideally, there would be a > way to specify what arguments the program takes, and the super-WB would > use this to prompt users for this info in some simple, consistent, and > non-troublesome way. And at this level, you could specify a file by > pointing to an icon. Any proposals for such a thing? No. I'm not sure that's the ideal, anyway. I think the programmer and the user have to know about the arguments the program takes. The programmer who writes for naive users needs to find some more friendly mechanism than command line options. If you use a program that accepts command line options you should be responsible for supplying them. All our super-WB needs to do is find a way of passing them along. The menu option that says "Set argument string" could do that. If the user selects it he gets a string gadget into which he types the arguments. The string gadget gets pasted on the command line after the program name and before the file names. > > But you still > > haven't solved the problem of redirecting standard input, I don't think. > > I think I have. What I haven't solved is the problem of command line > arguments. I still don't think so. You've just found another way to pass the files the user specified as command line arguments. Your "magic window" device could provide standard input by passing a file handle to the program at startup time. If the program tries to read from that file handle the device will open a window and accept input. If we can do it for an output window we can do it for an input window, I guess. But how do you redirect input? How do you tell the super-WB the file handle should point to a disk file instead of an input window? Selecting the files and dropping them on the program's icon (or using the present WB system for selecting the files and double-clicking on the program's icon should pass the names of the files as command line parameters. You still need something equivalent to "<" on your workbench screen. > > The program shouldn't know or > > care whether it was started from a CLI or from Workbench. > > Agreed, almost. I think the tool types of the WB are a very useful > facility (which should be extended). I wouldn't want them to go away. I'm not sure the tool types are that important. More important is knowing the default tool. There's no reason to do away with either, though. Just use the default tool to build a command line to pass to AmigaDOS. Tell me more about how you think the tool types should be used. Perhaps I'm missing something. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3