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)?
Thanks to everybody for putting up with my questions over the last few months. Oftentimes, just writing out the questions have been very useful to me, along with your responses. The good news is the book is almost done, and I hope that it will be an extremely useful reference.
Cheers!
Ben Root
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)?
Gtk came before Wx, and the mpl drawing model was influenced by that gtk heritage. (And on linux, Wx is a layer on top of Gtk.)
I have no idea what the consequences are of the subtle difference you point out, or whether it was a deliberate choice for some compelling reason, or whether it followed gtk but then gtk was changed later, or what.
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.
Eric
···
On 2014/11/23, 12:18 PM, Benjamin Root wrote:
Thanks to everybody for putting up with my questions over the last few
months. Oftentimes, just writing out the questions have been very useful
to me, along with your responses. The good news is the book is almost
done, and I hope that it will be an extremely useful reference.
Cheers!
Ben Root
------------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options
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
···
On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing <efiring@...229...> 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.
--
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.Barker@...236...
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.barker@…236…> wrote:
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
On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing <efiring@…229…> 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.Barker@…236…
–
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 -- so I'm no help there.
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?
I've toyed with using the guts of MPL as a generic
for-something-other-than-plotting AGG renderer. But I think it's fair to
not support that kind of use-case with guarantees of backwards
compatibility.
I do think a just-agg-drawing lib would be a nice think to have. So some
day, it may make sense to spilt it our out of MPL, and then we'd need to
worry about preserving the API, but while it's built into MPL, I wouldn't
worry about it.
-CHB
···
On Mon, Nov 24, 2014 at 9:41 AM, Benjamin Root <ben.root@...553...> wrote:
Ben Root
On Mon, Nov 24, 2014 at 12:28 PM, Chris Barker <chris.barker@...236...> > wrote:
On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing <efiring@...229...> 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.Barker@...236...
------------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options
--
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.Barker@...236...
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?
Because the backends are pretty close I would like to think we can modify them, but by my own experience this is not the case. Whenever you want to do something more (but not too much) you as user just tweak the backend.
That is one of the reasons behind MEP22. To offer a “clean” way to modify the backend without actually modifying it.
@tacaswell was working on a PR along the lines of making the backend components reusable (not just the canvas)
···
On 24 Nov 2014 12:42, “Benjamin Root” <ben.root@…553…> wrote:
Ben Root
On Mon, Nov 24, 2014 at 12:28 PM, Chris Barker <chris.barker@…236…> wrote:
On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing <efiring@…229…> 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.Barker@…236…
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