GUI maintainers: canvas.resize and ResizeEvent

I share Ted's concern. I think a 'well-behaved child widget' does not
know anything about its parent (or grandparent). Its added to a
container widget and expands/shrinks (depending on its resize policy) to
use the space that the container widget gives it. So the container
widget dictates the size of the child widget, not the other way round.

If you use the GUI to resize the canvas, you resize the gtk.Window and
the gtk.Window resizes the canvas. It seems reasonable to use the same
process to resize from a script - resize the gtk.Window and let the
Gtk.Window resize the canvas.
Or to put it another way - let the FigureManager manage the Figure!

I've updated backend_gtk.py to use this method, you can test it with:
$ ipython -gthread
In [1]: import pylab as p
In [2]: fig = p.figure()
In [3]: fm = p.get_current_fig_manager()
In [4]: fm.set_canvas_size(500, 600)

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com

···

On Fri, 2005-10-07 at 20:04 -0700, matplotlib-devel-request@lists.sourceforge.net wrote:

        If you can sketch a cleaner implementation that makes more
        sense let
        me know. Since only GTK has an implementation currently and
        it is
        broken, and no mpl code is currently using the resize
        function, the
        field is wide open.
        
        Thanks,
        JDH

I share Ted's concern. I think a 'well-behaved child widget' does not
know anything about its parent (or grandparent). Its added to a
container widget and expands/shrinks (depending on its resize policy) to
use the space that the container widget gives it. So the container
widget dictates the size of the child widget, not the other way round.

I'm also concerned about the resizable-children approach, and not just because it sounds scary. The result is a FigureCanvas widget that is strongly coupled to its parent widget. This poses a thorny problem for me because my WxMPL library subclasses FigureCanvasWxAgg and encourages people to embed that class directly in their own Panels, Frames, and whatnot.

If you use the GUI to resize the canvas, you resize the gtk.Window and
the gtk.Window resizes the canvas. It seems reasonable to use the same
process to resize from a script - resize the gtk.Window and let the
Gtk.Window resize the canvas.

I agree that this is a much more reasonable approach, and feel that its also more robust. This brings me to the point of this email: is this now the officially blessed way of implementing interactive GUI figure resizing?

Ken

···

On Oct 8, 2005, at 12:30 AM, Steve Chaplin wrote: