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 change it up so long as it works well
with Matplotlib, or should we be cautious and recognize that there are
users who go down beyond the canvas layer?
Ben Root
On Mon, Nov 24, 2014 at 12:28 PM, Chris Barker <chris.bar...@noaa.gov>
wrote:
> On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing <efir...@hawaii.edu> 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
>> > manager object (which, in turn, creates the window object) and hooks
>> > them all up. The manager would handle all window responsibilities such
>> > as creation/destruction and sizing. However, for the WX backend, this
>> > function just creates a FigureFrameWx object, which is the window
>> > widget. This object also becomes responsible for creating the canvas and
>> > the manager.
>> >
>> > This setup seems a bit backwards to me, but I am not entirely sure. It
>> > is definitely different. Does anybody know if it is merely a remnant of
>> > older designs (I think WX was the first backend)? What are the
>> > limitations of this approach, if any? Is there any interest in
>> > normalizing this backend design with the others (or vice versa)?
>>
>> In general, making the backends as similar as possible (and factoring
>> out as much as possible) is good; but actually messing around with these
>> things can be time consuming, painful, and hazardous. It's hard to test
>> with all the different platforms and versions.
>>
>
> Last I looked, and I doubt much has changed, the wx back-end required a
> fair bit of love -- there was a lot of extra refresh() calls being made in
> various places, most of which were unnecessary most of the time -- i.e. a
> bunch of extra refreshes. I've been hoping for literally years to find the
> time to go in an clean that up, but not yet....
>
> So -- if someone can dedicate some time to clean up the wx back-end, then
> it wold make sense to look into normalizing this, too. But I agree with
> Eric, this is likely to be a significant job -- wouldn't tough unless
> your'e ready to commit to some real work.
>
> If it ain't broke.....
>
> -Chris
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> chris.bar...@noaa.gov
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
