@wernerfb, it is good to see this work.
I think it should target 1.3 (the master git branch); the 1.2.x branch is for bugs, and this goes well beyond that. I suspect your changes could be extracted as a diff and then applied as a patch to a feature branch based on the current master, so they would be merged into a single clean commit. When you are working on a feature branch, it is better not to merge anything into it from the main branches. Instead, if your feature branch does not merge cleanly into its target, because of changes in the latter, it is best to rebase it so that it will merge cleanly.

Hi Eric,

On 11/05/2013 23:53, Eric Firing wrote:

@wernerfb https://github.com/wernerfb, it is good to see this work.

I think it should target 1.3 (the master git branch); the 1.2.x branch
is for bugs, and this goes well beyond that. I suspect your changes
could be extracted as a diff and then applied as a patch to a feature
branch based on the current master, so they would be merged into a
single clean commit. When you are working on a feature branch, it is
better not to merge anything into it from the main branches. Instead,
if your feature branch does not merge cleanly into its target, because
of changes in the latter, it is best to rebase it so that it will
merge cleanly.

I am very new to git and I can't build mpl locally, that is why I did it
against the tag for 1.2.0.

If I understand your suggestion correctly, I should use "rebase" on my
local clone to 1.3, push the change and I assume I would then need to do
another pull request?

Werner

Werner, yes, you would rebase on current master and make a new pull request with master as the base. Be sure to use a feature branch, however--see http://matplotlib.org/devel/index.html for some workflow tips. I think it would be by far the best if you could build mpl locally, so you could fully test your changes in the normal way. Also, because this involves testing with a very new and not widely distributed version of wx, it might take a while before others are able to test it, so maybe the 1.3 target is too optimistic.

There have been quite a few changes in backend_wx* from 1.2.x to master, and it looks like more are needed even without the Phoenix compatibility changes. I'm not sure whether it would be better to try to use git to rebase, or whether it might be easier to essentially re-do the changes directly on master. If you run into trouble with the former, you can always fall back on the latter.

I think there may be quite a bit of testing and work required to make sure these sorts of changes work on sufficiently old versions of wx--and some thought may need to go into the question of how old a version we need to support here.

It looks like the rebase was clean, I'll push that in a little while.

I don't think I will find time in the near future to figure out what I need to build 1.3 locally (don't I need a C compiler etc etc), are there preview builds for win 32 I could maybe use?

It would be great if this would make it into 1.3 and as the latest changes should be compatible with wxPython 2.8+ classic and 2.9.5 Phoenix this should be possible no? At least this way it gets more testing, even if mostly with wxPython classic.

I am closing this because it is replaced by #1995.
I agree with your comment above, @wernerfb, that #1995 appears to be fully compatible with non-phoenix wx, and if so, it should be possible to merge it quite promptly.