Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!lll-winken!taco!hobbes.catt.ncsu.edu!kdarling
From: kdarling@hobbes.catt.ncsu.edu (Kevin Darling)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Some WB2.0 Peeves
Message-ID: <1991Jun28.025117.23230@ncsu.edu>
Date: 28 Jun 91 02:51:17 GMT
References: <1991Jun24.000524.378@mintaka.lcs.mit.edu> <1991Jun25.032545.7153@marlin.jcu.edu.au> <1991Jun25.112729.27772@mintaka.lcs.mit.edu> <14296@goofy.Apple.COM>
Sender: news@ncsu.edu (USENET News System)
Organization: North Carolina State University
Lines: 27

lsr@Apple.COM (Larry Rosenstein) writes:
>>>formating a disk in another window.  Everything stops if you move a
>>>window, or access a menu.  Put simply it sucks, and I hope it gets 
>>
>>  This seems like a matter of opinion, but how long do you stay in
>>menus or dragging a window? Do you move windows around and can't decide
>>where to put them? (Does it look good here? no maybe it will look good
>
>I find this highly amusing, since this is the example people use to show
>why MultiFinder is so inferior to the Amiga O/S.

Ha! <giggling insanely>  Methinks both systems can go fly a kite in this area!

My own opinion: a multitasking machine should _always_ multitask, not flake
out simply because of some weak "cpu-speed" or "GUI speed/need" cop out.
Performance issues?  Make me laugh.  _Any_ speed is faster than being STOPPED!

Under ver3.0 of OS-9 for the 6809-based CoCo-3, neither window moves/resizes
nor menu pulldowns stop any of the other windows from continuing output.
(Altho the menus were easy: they are contained per window, not at the top :)

Furthermore, you can even move a window to _any_ other open gfx screen!
(just "pick" it up, click around on the next-screen mouse button, and click
the window back down wherever).  Try that, y'all!  ha! HA! HAHA! HAHAHAHA!

Harumph!  Wimp excuses, everywhere.   Kevin <kdarling@catt.ncsu.edu>
                                      Yes, I coded it. So sue me. :-)