C506634@umcvmb.missouri.edu (Eric Edwards) (04/03/89)
Thought I'd put in my 2 cents worth since everybody else already has.
How about have the Workbench multitask with itself?
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 do
ne.
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.
Oh, yeah. Make info multitask. The current situtation is absurd.
Bitnet: C506634@umcvmb.bitnet __________________________
Internet: C506634@umcvmb.missouri.edu / \.--------. / \
"The Amiga just isn't reliable enough unless you | | Eric |---------+ |
know a lot about the machine" -- Jerry Pournelle | `--------' ! |
================================================|| .--------. ! |
"I did notice that at my party people stood in | | Edwards|_________+ |
line to play with the Amiga"-- Jerry Pournelle | /`--------' |
BYTE, October '88 \__________________________/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...
david.mercer@canremote.uucp (DAVID MERCER) (04/05/89)
My favourite is using the icon editor, with no size gadget, so that to see how your icon fits in with the others, you have to quit the program. --- * Via ProDoor 2.9a --- MaS Relayer v1.00.00 Message gatewayed by MaS Network Software and Consulting/HST Internet: david.mercer@canremote.uucp UUCP: ...!tmsoft!masnet!canremote!david.mercer