self.canvas.set_size_request(w,h)
I've thought about this a little more and realize we have to proceed
with some caution. A minor nit is that set_size_request is the wrong
name, since this sets the minimum size in the GTK API, which is not
what we mean. We want something like "resize". Here is an
implementation for gtk which can be called on the canvas and resizes
the window to account for the other objects in the window
def resize(self, w, h):
"""
set the canvas size in pixels
"""
# the window size
winw, winh = self.parent.parent.get_size()
tmp, tmp, myw, myh = self.get_allocation()
padw = winw-myw
padh = winh-myh
neww = w+padw
newh = h+padh
self.parent.parent.resize(neww, newh)
The question is: how do we want to expose this? If the user calls
fig.set_figsize_inches, should the Figure forward the call to
canvas.resize? We have to be careful of a potential infinite
recursion, because the resize method will trigger a GUI resize event
which calls fig.set_figsize_inches in the various backends.
We could define an optional kwarg to fig.set_figsize_inches, eg
def set_figsize_inches(self, w, h, forward=False):
where when forward is False the call is not forwarded on to the
canvas. This would enable the canvas to set the figure size on mouse
resizes, the typical case, w/o triggering the infinite recursion.
My inclination is to support the user being able to use either the
fig.set_figsize_inches method or the canvas.resize method because
sometimes it's more natural to think in terms of inches and sometimes
pixels.
class Canvas:
def resize(self, w, h):
# resize the window/canvas this will automatically trigger a
# GUI resize event that will cause the figure size to be updated
# because the various backends already call set_figsize_inches on
# resize events
class Figure:
def set_figsize_inches(self, w, h, forward=False):
# by default this will not forward events to canvas.resize
# but when forward is True call self.canvas.resize
This prevents the infinite recursion on mouse resizes (the resize
event calls set_figsize_inches and the event is not propagated back to
canvas.resize).
The user who *wants* to resize the canvas, eg from the shell, calls
fig.set_figsize_inches(w, h, forward=True)
which triggers canvas.resize(w,h) which triggers the GUI resize event
which in turn calls fig.set_figsize_inches(w, h, forward=False) and
the recursion is blocked. It seems a bit strange that
fig.set_figsize_inches triggers a call to itself, but this is where my
screwy Friday afternoon logic has led me in thinking about how to
support resizes in the three ways people want to do it
* with the mouse
* with fig.set_figsize_inches(winch, hinch)
* with canvas.resize(wpixe, hpixel)
On light testing, this appears to be working in GTK:
Checking in lib/matplotlib/figure.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/figure.py,v <-- figure.py
new revision: 1.37; previous revision: 1.36
done
Checking in lib/matplotlib/backends/backend_gtk.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/backends/backend_gtk.py,v <-- backend_gtk.py
new revision: 1.112; previous revision: 1.111
Or is there a simpler solution that is escaping me?
JDH