OK, I think I finally got this API to be at once simple, extendable,
powerful and much easier to explain than before. Thanks to Josiah for
ideas and the push to question the initial designs.
So now one can get away with just
delayedresult.startWorker(consumer, workerFn)
in a lot of cases, with just a couple more args to cover 99% of what's
left. The consumer is used to select between wx.PostEvent (if it derives
from wx.EvtHandler) or wx.CallAfter (all other cases). Consumer can be
any callable.
This allows for the chain stuff to be a separate wrapper, out of the
way, no need to discuss it to understand the module, no need to use it
if you don't like it. StartWorker is not necessary, one can directly use
a delayedresult.Sender and a delayedresult.Producer or other thread
module. Etc.
And I can still do the zillions of things I could with the old API, but
now it is tons simpler to explain.
I'll create a small example of use for the wx demo and send it.
Cheers,
Oliver
testDelayedResult.py (5.77 KB)
delayedresult.py (14.6 KB)
···
-----Original Message-----
From: Josiah Carlson [mailto:jcarlson@uci.edu]
Sent: September 1, 2006 5:43 PM
To: Oliver Schoenborn; wxPython-users@lists.wxwidgets.org
Subject: Re: [wxPython-users] Latest DelayedResult implementation[...] Keep it simple. Keep
it fool-proof. There are so many steps in the construction
and use of channels, ports, senders, etc., within
DelayedResult that people are going to get bogged down.[...]
To make people understand something that is difficult to
understand, you don't make it more complicated (with more
pieces), you make it easer.
Simplify, simplify, simplify!What is the goal? Run a (long-running) computation outside
of the GUI thread and get the results back (or an exception)
via a user-specified
mechanism: wx.CallAfter, wx.PostEvent, direct calling, etc.[...]
