Pending release of 0.3

[Chris Colbert]

crap, I hit send too soon.

continuing on...

for the pygtk plugin:

def __app_show():
     window_manager.register_callback(gtk.main_quit)
     gtk.main()


Thus, the window manager represents a universal manager that is
applicable to every image plugin.

You can make super complex gui window widgets, just register it with
the manager.
Since imshow takes *args, and **kwargs, you could in theory do this:

imshow(img, mybadasswindow=True)

and your plugin behaves appropriately.

Cheers!

Chris

On Wed, Nov 4, 2009 at 10:44 AM, Chris Colbert <sccolbert at gmail.com> wrote:
> The plugin system makes it extremely easy to make any kind of display
> plugin you want. You just have to provide at least two methods and
> shake hands with the window manager.
>
> your plugin must provide the following two functions:
>
> imshow(img, *arg, **kwarge)
>
> and
>
> __app_show()
>
>
> you must also "shake hands" with the window manager.  A common
> occurance in the gui tookits is the windows opened from within
> functions during an interactive python session will be garbage
> collected after the function returns and they fall out of scope. Thus
> the window manager maintains a reference to the window until it is
> closed. Also, because the gui toolkits set PyOS_InputHook, we have to
> make sure that only one gui kit gets imported in a session (some kits
> will trample on other, but not vice-versa) so the window manager also
> implements a "gui lock" that you must acquire before using it or your
> gui kit:
>
> from util import window_manager
>
> window_manager.acquire('qt')  #or 'gtk' or 'mybadassplugin'
>
> then evertime you create a window, register the main_window handle
> with the manager.
>
> window_manager.add_window(mynew_window)
>
> Then, make sure that mynew_window's destroy event, whatever that may
> be, makes a call to window_manager.remove_window(mynew_window)
>
> The window manager also implements a callback that can be set, that
> will be called when there are no more registered windows.
> This was necessary for non-interactive sessions, so you can kill the
> event loop. This is also the reason for __app_show():
>
> You're plugin must also define an __app_show() method. When not
> running interactively (i.e. from a script), calls to imshow() will
> queue up windows, but without a gui mainloop running, they will never
> display. When a user calls show(), this calls your plugins
> __app_show() method, which should do two things:
> 1) register a callback with window_manager that will be called when
> all windows are closed and will cause the event loop to exit (this may
> not be required for some kits. i.e. PyQt4)
> 2) start the mainloop
>
> for the pygtk plugin, it looks like this:
>
> def __app_show():
>
>
> On Wed, Nov 4, 2009 at 7:53 AM, SirVer <sirver at gmx.de> wrote:
>>
>> Hi Stefan,
>>
>> I do not know were I'm currently at. My gui branch is not merged to
>> master, so I guess you are unhappy with it. There is other development
>> based on the plugin architecture and we have now yet another image
>> viewer in pyqt. Still I feel that a full featured gui module could
>> lead to much more powerful image processing widgets than the plugin
>> system could. So I am unsure if and if yes how I should advance with
>> my gui & camcalib branch.
>>
>> Cheers,
>> Holger
>>
>> On 3 Nov., 22:40, Stéfan van der Walt <ste... at sun.ac.za> wrote:
>>> Hi all,
>>>
>>> I am planning to tag version 0.3 by the end of this week or early next
>>> week.  Please let me know if there are any branches I should review
>>> before then.
>>>
>>> Happy hacking!
>>> Stéfan
>