🚀 go-pugleaf

innuendo@execpc.com (Jonathan Gapen) writes:

>   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.

Correct.

>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.

That's a flaw in this particular gadget. As the program causes the
updates of the channel text gadget this should run on the program's
context of course. I'm still wondering how it stops input.device.

>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.

Or don't use just a particular task. Some operations on the gadget
need immediate response like the visual appearance of a button click,
the knob of a slider moving or the update of the value. These
operations are best run on the input.device context because this
avoids overhead. Anything that needs more time and isn't expected
to happen "immediately" can happen on the user's program context
or another task.

There is one implementation problem with rendering BOOPSI gadgets. This
is not a problem of BOOPSI or input.device, it is a problem of the
implementation of gadgetclass. This class doesn't support clipping of
gadgets and this was one major obstacle to implement MUI with standard
gadgetclass objects and is also a reason to render gadgets on the user
context.

BTW, ClassAct solves this problem with a new method. But this also
means that you can only clip ClassAct gadgets and not other regular
gadgetclass gadgets.

Regards,
-- 
                                Michael van Elst

Internet: mlelstv@serpens.rhein.de
                                "A potential Snark may lurk in every tree."