🚀 go-pugleaf

In article <4jfqpe$nem@nntp1.best.com> djm2@Hovercraft.msstate.edu (Dan Murrell Jr.) writes:
> 
> MUI is BOOPSI too.  Although it's classes are specific to MUI and the context in
> which they run causes MUI apps to "stall" occasionally.  Normal Intuition BOOPSI
> runs on a context independant of the app.  Normal Intuition BOOPSI classes can
> be updating themselves despite what the program is doing.  For example, and this
> is probably a bad one but nevertheless, AWeb and IBrowse both crash.  If you resize
> AWeb's window, the gadgets will still resize.  If you resize IBrowse's window, the
> gadgets will just be dead.  Even if AWeb itself is dead, the gadgets are still 
> "alive" unlike the MUI gadgets of IBrowse which will be dead because the app is
> dead.

   When MUI became popular, I saw users touting it because all gadget updates
happen on the application context.  Now, we get MUI haters touting BOOPSI
because all gadget updates occur on the input.device context.  Who to believe?
   Well, I say neither.  Each method has its advantages and disadvantages.
For instance, take Grapevine.  When updates of the channel text gadget occur,
my mouse pointer stops dead for a short period.  While that's not too bad,
it's when it happens repeatedly that it gets annoying.  This effect is also
noticable in other applications with complex gadgets to update.  Also, since
some of the application code is running under the input.device context, if it
has bugs, it's more likely to lock out all user input if the application locks
up.
   On the other hand, MUI programs just simply lock up, very rarely shutting
down the input.device.  When they do lock, you can tell immediately, since all
the gadgets stop responding, which in that case is a good thing.  However, it
is annoying that the gadgets don't respond if the application is busy, which
can happen, from time to time.
   On the whole, I don't think it makes much difference.  You get the rare
cases like Grapevine which make the system annoying to use, and a MUI program
or two which doesn't use a busy pointer properly, but they mostly behave alike
on my system.  Perhaps the ideal solution would be to update gadgets in the
context of some other task, neither the application context, nor input.device.
Discussion of how to do that, if possible, is better left for another time.

-- 
Jonathan Gapen (innuendo@execpc.com)
Bread in, toast out. How does it DO that?