eachus@mbunix.mitre.org (Robert Eachus) (04/04/89)
In article <12137@louie.udel.EDU> C506634@umcvmb.missouri.edu (Eric Edwards) writes: >As it stands now, when you load a program or do any other task that >requires a non-trivial amount of time you get a 'zzz' pointer and >must wait until it is done. >Why not have the Workbench launch a new task whenever it does these >tasks. That way the user could still use the workbench while it >loaded a program, delete a drawer, etc. Taken to the extreme one >might never have to the zzz pointer again. There is an elegant way to do this "right" and if Workbench is to be fixed, doing it right is, in fact, probably a lot easier than fixing all the things that are broken. The Workbench should consist of two main tasks, the fist of which interacts with the user, and the second, "the daemon" interacts with the disks. A user request (double click) to open a disk would require the first task only to send a message to the daemon to open that window. As the daemon retrieved .info files it would sent messages (not replies, the initial reply corresponds to request recieved) to the Workbench task containing the locations of the data. (Who manages clean-up, etc. is an implementation detail, but I would put it in the daemon.) This way the Workbench should only sleep when, for example, it is waiting to reload a library that was flushed. If the interface is kept clean, it should be possible to write a program (with an AREXX interface, of course) which would do nice things like open a disk (or some particular nested directory) on the workbench from the CLI or your startup, by sending requests to the daemon. (The Workbench process won't get confused. All it "knows" is to send requests to the daemon on some user inputs, and to display .info files when the daemon sends them. It doesn't "see" any relation between the two.) P. S. I am cross-posting because this really belongs in .tech, so please followup there only. Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
c60c-1ea@web-1d.berkeley.edu (Yen Yuanchi Hsieh) (04/11/89)
In article <47878@linus.UUCP> eachus@mbunix.mitre.org (Robert I. Eachus) writes: > The Workbench should consist of two main tasks, the fist of which >interacts with the user, and the second, "the daemon" interacts with >the disks. A user request (double click) to open a disk would require >the first task only to send a message to the daemon to open that >window. As the daemon retrieved .info files it would sent messages >(not replies, the initial reply corresponds to request recieved) to >the Workbench task containing the locations of the data. (Who manages >clean-up, etc. is an implementation detail, but I would put it in the >daemon.) My replacement (sans INFO window as of now :-< ) consists of four tasks -- disk, window, input (user), and a server to tie all of these, and any other programs that want to be attached into the system, together. >...interface, of course) which would do nice things like open a disk (or >some particular nested directory) on the workbench from the CLI or >your startup, by sending requests to the daemon. (The Workbench >process won't get confused.) Yep, I could do that with my program -- would be very simple, actually. I've already written things to: place a pattern on the backdrop window, wrote a calculator that takes input from whatever window (Workbench inclusive) you're in, iconizes windows, rubber-bands open/close windows, puts audio samples for beeps, and the list goes on... >P. S. I am cross-posting because this really belongs in .tech, so > please followup there only. Okay... :-) > Robert I. Eachus > >with STANDARD_DISCLAIMER; >use STANDARD_DISCLAIMER; >function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is... If I had any ideas, they'd be my own, but as it stands.... :-) David Navas