Update event model

[jarvisteach]

Improve the way users register events

At the moment, it's only possible to have one event loop, and the user has to manage how many times it gets called.

Would be nice to offer a better model:

• Each event in its own loop
• Each loop has its own delay
• Each loop has its own number of repeats
• Each loop repeats until the function returns True

So, .registerEvent(function) could have additional parameters:

• count - how many times to repeat the function (defaults to infinite - None)
• sleep - how long to sleep between function calls (defaults to 1 second)
• checkResult - keep repeating until the function returns True (default to off)

Becoming: .registerEvent(function, sleep=1, repeat=None. checkResult=False)

.setPollTime() then becomes deprecated - but will adjust the default delay time above.

Also, some way to sleep for x amount of time. This could be provided as: .sleep(time). It would wait the specified amount of time before returning control back to the calling function. But it won't block the main loop, so the UI will remain responsive.

[jarvisteach]

Interesting way of running loops: https://gist.github.com/niccokunzmann/8673951

[jarvisteach]

Some good discussion on threading in tkinter: http://stackoverflow.com/questions/16745507/tkinter-how-to-use-threads-to-preventing-main-event-loop-from-freezing

[jarvisteach]

An additional function .callEvent(function) that wraps around the above to call a function once - sets repeat to 1.

[jarvisteach]

NB. The docs are VERY misleading - .after() doesn't kick off processes in new threads, and will cause the event loop to hang...

[jarvisteach]

We now have a few new features.

• A function queue - users can queue function calls, that get processed in the GUI loop, ensuring no thread conflicts.
• As the Queue is threadsafe, these function calls can be queued from external threads.
• A thread function, that can be passed a function to run in a thread, so that the GUI doesn't hang. Any GUI updates should be passed to the function queue.

This is a fairly complex model, but should allow for a reliable process.

The threads are set as Daemon threads - so if the GUI is quit, the threads will be terminated.

In an attempt to support as many versions of Python as possible, the threading is fairly basic - there's no limit on thread numbers, and each time the thread function is called a new thread is instantiated. Both of these could be improved.

There's also currently no thread monitoring - it would be nice to subclass Thread, and have threads store a running time and call something on completion...