Reading through the backend_wx.py code, I noticed a small deviation from
the other interactive backends. All other new_figure_manager_given_figure()
separately creates a canvas and manager object (which, in turn, creates the
window object) and hooks them all up. The manager would handle all window
On 2014/11/23, 12:18 PM, Benjamin Root wrote:
> Reading through the backend_wx.py code, I noticed a small deviation from
> the other interactive backends. All other
> new_figure_manager_given_figure() separately creates a canvas and
> manager object (which, in turn, creates the window object) and h
On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing wrote:
> On 2014/11/23, 12:18 PM, Benjamin Root wrote:
> > Reading through the backend_wx.py code, I noticed a small deviation from
> > the other interactive backends. All other
> > new_figure_manager_given_figure() separately creates a canvas and
> >
It is odd you mentioned the extra refreshes. I have to double-check my book
examples, but I think I found that I needed to add some extra draw_idle()
calls when using native wx widgets.
This does raise another point. As a development policy, how should we treat
the backends? Should we be free to c
On Mon, Nov 24, 2014 at 9:41 AM, Benjamin Root wrote:
> It is odd you mentioned the extra refreshes. I have to double-check my
> book examples, but I think I found that I needed to add some extra
> draw_idle() calls when using native wx widgets.
>
I haven't messed with widgets within MPL at all
On 24 Nov 2014 12:42, "Benjamin Root" wrote:
>
> It is odd you mentioned the extra refreshes. I have to double-check my
book examples, but I think I found that I needed to add some extra
draw_idle() calls when using native wx widgets.
>
> This does raise another point. As a development policy, how
