John, I had some questions about this resize work. Here is
> the code for resize from backend_gtk.py:
> def resize(self, w, h): 'set the drawing area size in
> pixels' winw, winh = self.parent.parent.get_size() tmp, tmp,
> myw, myh = self.allocation padw = winw-myw padh = winh-myh
> self.parent.parent.resize(w+padw, h+padh)
> I'm a little concerned about this implementation. It looks
> like the widget is telling it's parent's parent to resize.
> Doesn't this mean that the ability of the widget to be used
> as a modular component is reduced because this code requires
> a certain parent child relationship?
Oops, you're right. Good catch. This implementation will fail for
some widget packings, eg a canvas in a scrolled window...
> I think it's fairly important that a widget have only very
> minimum interactions with it's parent. Is there some way
> this could be implemented that doesn't require the child
> widget to be calling methods on the parent?
> If I understand the basic premise you've outlined below, you
> want a resize in the child (the drawing widget) to cause the
> parent window to resize. Only the parent can figure out what
> it's size needs to be (since it knows about it's margins,
> toolbars, etc). On the surface, it seems like there are two
> ways to handling this: 1) Tell the window to resize the
> canvas. The window can use it's own layout classes, etc and
> correctly resize itself and the canvas. 2) Tell the canvas
> to resize and have this trigger a window resize.
> I think the first option is much cleaner. However, if that
> isn't possible, I suggest that we do something like this:
Right, we don't need a resize method. As you suggest, all we need
is a way to tell the canvas and its parent(s) to auto_adjust itself to
accommodate the figure (using the width, height and dpi settings ....)
Then whenever fig.set_dpi or fig.set_figsize_inches or
fig.set_figsize_pixels (to be added) is called, we could call
self.canvas.update_size()
if we can figure out the right way to propagate up containment chain.
The update_size method will have to send a signal to the parent, but
how this is done can be backend dependent. I think the logic in my
first implementation is still correct if we replace self.parent.parent
(which as you note makes certain parent/child assumptions) with the
gtk.Window the canvas resides in because it sets it computes the width
and height of all the other widgets in the canvas by subtracting the
canvas width/height from the window width/height.
winw, winh = self.gtkwin.get_size()
tmp, tmp, myw, myh = self.allocation
padw = winw-myw
padh = winh-myh
self.gtkwin.resize(w+padw, h+padh)
Of course this would require that the canvas user sets gtkwin. Other
than for the philosophical reason that the child calls methods on the
parent, do you still think this implementation is problematic? I
personally don't find it problematic, but I'm willing to be corrected
Of course, in QT you could handle it anyway you want, eg using
signals to the parent.
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