Request for review / progress updates

[Chris Colbert]

How do we want to handle the threading/blocking issues that will
result from  various imshow plugins?

For example, right now, I could write a plugin that uses OpenCV's
highgui to show an image, but if I dont spawn a worker thread, this
will be a blocking function.
If I do spawn a worker thread, I will need to create a wrapper class
in Cython, so that I can __dealloc__ the appropriate gui bits, once
the thread dies.

Obviously, the former is easier to get running. But which way should
we handle this?

Maybe we can think about creating our own universal "gui-thread
service", where we pass a blocking function to be executed and
call-back to be executed once that function returns.
The service can then handle the threading a checking.

Just an idea.

Chris

2009/11/1 Stéfan van der Walt <stefan at sun.ac.za>:
>
> 2009/11/1 Ralf Gommers <ralf.gommers at googlemail.com>:
>>> http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/matplotlib_plugin.py
>>>
>>> http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/pil_plugin.py
>>>
>>
>> That looks promising! It all works for me, and it's easy to understand.
>>
>> The one thing I can think of after quickly looking through it, is some
>> convenience funcs to get/set the defaults for the plugin, both for all
>> keywords in plugin_store or for a single keyword. This will help when
>> plugins start to overlap in functionality. I would for example like to be
>> able to set MPL to be the default for showing/saving, and PIL for loading,
>> without having to use plugin='...' each time.
>
> This is now implemented in
>
> http://github.com/stefanv/scikits.image/tree/io
>
> For example, you can do
>
> plugins.use('PIL')
>
> or
>
> plugins.use('PIL', 'show')
>
> Please review so we can merge / work on it some more.
>
> Cheers
> Stéfan
>