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@sun.ac.za>:
2009/11/1 Ralf Gommers <ralf.gommers@googlemail.com>:
http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/matplotlib_...
http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/pil_plugin....
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