SourceForge logo
SourceForge logo
Menu

Re: [matplotlib-devel] Resize bug in tkagg backend

From: Ted D. <ted...@jp...> - 2006年01月27日 16:17:49
Fernando,
This looks like you're using the Tk backend. This is one of the problems 
with trying to use a very common method name in widgets like 
resize(). Different GUI packages can define it differently. It looks like 
Tk uses this for it's resize event handling while Gtk and Qt use resize( w, 
h ) for controlling size and other method names for the event handling like 
resizeEvent().
After some digging, I think this looks like it might be a bug (or at least 
a head ache) in the Tk backend design. In backend_bases.py, there is this 
code:
class FigureCanvasBase:
 ...
 def resize(self, w, h):
 """
 set the canvas size in pixels
 """
 pass
Presumably, this is sort of a default implementation for a virtual method 
that others can rely on. However, in backends/backend_tkagg.py we have this:
class FigureCanvasTkAgg(FigureCanvasAgg):
 ...
 def resize(self, event):
 width, height = event.width, event.height
 ...
And if you look in backends/backend_agg.py you'll see this:
class FigureCanvasAgg(FigureCanvasBase):
 ...
So FigureCanvasTkAgg is inheriting from FigureCanvasAgg which inherits from 
FigureCanvasBase which has a resize( w, h ) method. However, 
FigureCanvasTkAgg re-implements resize with a different signature. At best 
this very confusing.
It looks like FigureCanvasTkAgg.resize is used as a callback in the ctor 
for that class for one of the Tk events. Here's what I'd suggest:
1) Rename FigureCanvasTkAgg.resize( event ) to FigureCanvasTkAgg.resize( w, 
h ).
2) Move the code that extracts the w, h from the event to a new method 
FigureCanvasTkAgg.resizeEvent( event ) like this:
class FigureCanvasTkAgg:
 def resizeEvent(self, event):
 width, height = event.width, event.height
 if self._resize_callback is not None:
 self._resize_callback(event)
 self.resize( width, height )
3) Change the FigureCanvasTkAgg ctor to use the resizeEvent callback 
instead of resize.
WARNING: I don't know anything about Tk! I'm hoping someone that does now 
Tk can check this over and make sure it sounds right.
This of course doesn't actually do anything for fixing the problem we've 
been discussing about how to resize a plot after it's been created and have 
the window update accordingly.
Ted
At 11:08 AM 1/25/2006, Fernando Perez wrote:
>Ted Drain wrote:
>>Maybe one of you guys could refresh my memory. What is the calling 
>>sequence we're going for?
>
>My original message was this:
>
>============================================================================
>In [1]: gcf().set_figsize_inches((8,8),forward=True)
>---------------------------------------------------------------------------
>exceptions.TypeError Traceback (most recent
>call last)
>
>/home/fperez/code/python/pylab/arrows/<ipython console>
>
>/usr/lib/python2.3/site-packages/matplotlib/figure.py in
>set_figsize_inches(self, *args, **kwargs)
> 266 canvasw = w*dpival
> 267 canvash = h*dpival
>--> 268 self.canvas.resize(int(canvasw), int(canvash))
> 269
> 270 def get_size_inches(self):
>
>TypeError: resize() takes exactly 2 arguments (3 given)
>
>
>A quick look at the backends code shows this:
>
> def resize(self, event):
> width, height = event.width, event.height
> self.toolbar.configure(width=width) # , height=height)
>
>So quite obviously, this doesn't work: it's expecting an event object, and a
>pair of numbers is being passed.
>
>I'm not sure what the proper fix should be here, I don't really know the code
>flow well enough.
>
>I should also note that the gcf().set_figsize_inches((8,8),forward=True) seems
>to produce a different on-screen result per backend (in some it doesn't do
>anything, in Qt it stretches the figure only horizontally, ...) That code
>seems to be pretty much broken.
>
>I noticed that figure(figsize=(8,8)) seems to work fine, but I'm not sure how
>to programmatically resize an existing figure, given the above problems.
>============================================================================
>
>Beyond this, I'll leave it to the backend experts as to what the right 
>choices should be. I just noted that shipping a feature _known_ to break 
>on all but one backend doesn't sound like the best approach :)
>
>Cheers,
>
>f
Ted Drain Jet Propulsion Laboratory ted...@jp... 

View entire thread

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /