I like the idea, but I think it would be better to do it after the Plt/GFC refactor.
If the refactoring is well done, we will have a nice window stuff separated from the rest, then this will be easier to implement.

I'm sorry but I will have to pass on this one, it is tempting to do it now, but the more changes we do, the less probable for the PR to be accepted.
I really want the PR to be accepted so I can move on with my multi figure manager, that is my real objective.

I understand and agree with your comments, I had those concerns also, but the large number of deletions (and very few insertions) to the backend (gtk3) swayed me, together with the comment by @tacaswell matplotlib#2624 (comment)

Do you have any idea how long until the Ptt/Gcf refactor will come out? I.e. do you think it will make it out before more backends get converted?

And yes, I really want to see your navigation thing go through (though I do have a few more suggestions to make).

One last thing, if in the future this does go though, I have one more modification to this PR to commit.

I have no idea when the Plt/Gfc refactor will come out.
Other idea that crossed my mind, was to implement the https://github.com/matplotlib/matplotlib/wiki/Mep23 as a new set of separated elements (kind of the refactor). That way, there is no backwards incompatibilities, and a "smooth" migration for the users would be possible.

If you want, just make the change to his PR, so the idea is not lost.

@OceanWolf do you mind rebasing this PR? I want to take another look

Ooh, sure thing :)! Not right now though, just decided to travel long distance tonight, so busy packing.

In the mean time could you take a look over my most recent PR #9? Then I can rebase and finish #6 :).

I don't get this rebase, it says I have merge errors in files I haven't touched, i.e. lib/matplotlib/backends/backend_tkagg.py. Confused...

Are you rebasing against my branch? or against master?
In my case, in the last rebase I had the same problem, because in upstream (matplotlib/master) there was a conflict with an early modification to that file, from the time I was trying to carry both backends at the same time.

Actually what I was trying to do to resolve the problem was to remove my modifications to that file from the repository, but messing with history is dark magic.

So, what I recommend is just open the file, and resolve the conflict removing my part that is in conflict

Yes, against your branch.

git checkout navigation-by-events
git fetch upstream
git merge --ff-only navigation-by-events
git checkout navigation-by-events-subplots-tool
git rebase navigation-by-events

It gives me warnings about 5 lines containing whitespace errors and fails to merge Patch failed at 0001 tk backend. I think this happens because I rebase from a rebase, which means that your history has changed, and thus the diff looks to the wrong commits to compare with... when you look above to what github now sees as the files changed, you see it thinks that I want to add the entirety of navigation... very bizarre, it seems unable to a diff and see that no differences exist...

Should I try and delete my branch locally and rebranch from navigation-by-events? I could then do a git push --force.

And remove the Tk work? Updating the Tk work comes as the next task on my hit list of PRs, i.e. after my internal meddlings.

I wanted to remove the Tk work and leave it for when the main PR is accepted, but honestly I didn't know how to do it.
I don't want to maintain two different backends while developping the mechanics

Regarding the rebase, I find that sometimes it is easier to just create a new branch, instead of trying to keep up with conflicts like this.

Yes, I think I will make a new branch, while the commits/files changed looks a mess on github, naturally as I haven't rebased, it looks fine locally. I wonder if I should do the following (even wondering if it will work):

git checkout navigation-by-events-subplots-tool
git checkout -b navigation-by-events-subplots-tool-backup
git checkout navigation-by-events
git branch -d navigation-by-events-subplots-tool
git checkout -b navigation-by-events-subplots-tool
code code code
git commit -a
git push origin --force

i.e. the aim of pushing back to this PR, but with a new fresh history.

And yes, I completely agree with you on not working on Tk while developing internal mechanics, it makes no sense with it all in flux, though as I say, I see that stage as almost over, then I see no reason why not to get Tk patched up. Both because of external mechanics, i.e. with specific tools, I want to see if they will work on both backends; and because it feels nice to have a fully polished PR to show to the owners, the (i.e. not a, it works, but don't look there, or there thing).

@OceanWolf Do you mind to give it a try to rebase or recreate this PR? I am interested in your work on the window stuff, I am pretty sure I will need this for my multifiguremanager

Sure, I really want to give this a rebase ASAP, but first I want to get the window stuff redone, as this subtool basically added some nasty hacks because of the lack of a WindowBase, so I want to get that work done first. It shouldn't take too much longer to get it to a finished state with all the backends. The more backends I upgrade the faster it will go.

I haven't done anything weird with the code, all fully backwards compatible, just like MEP22. But unlike MEP22, a pure refactor, no change in behaviour, no extra features, so I think/hope it will get accepted quite easily. Interested in your comments, but please put them into that PR, I would like to keep comments as concentrated as possible. Also note that the closer the code lies to the backends, the more likely it will change as I refactor more backends. Hoping to get Tk finished today, very nearly done :).

Naturally once I have completed this refactor, if it looks like it will take a while to get the thumbs up, then I shall move on to this regardless, but I would like to get refactored window code sitting there first.