This incorporates the functionality I believe was intended in the show() function. This allows for show to bring the figure to the front of the display when issued. In an interactive session, this allows for a user to develop code to bring selective windows to the front (as the macosx renderer is a separate app from the interpreter running)

The following code demonstrates the usefulness

import matplotlib.pyplot as plt
import time
import numpy as np
fig1 = plt.figure()
plt.plot(np.arange(10), 'b')
fig2 = plt.figure()
plt.plot(np.arange(10), 'r')
fig3 = plt.figure()
plt.plot(np.arange(10), 'g')
fig2.show()
time.sleep(1)
fig1.show()
time.sleep(1)
fig3.show()
time.sleep(1)

@mdehoon: Any unintended consequences?

@cimarronm: Would you mind adding an entry to whats_new.rst?

I am not sure if this is how show() is supposed to work. Without this patch, the MacOSX backend behaves the same as the tkagg backend. After this patch, they behave differently.

@mdehoon Is there any reason this should not be the default behavior then? Perhaps, tkagg/other backends should be changed as well to act in the same fashion. I think that would be more desirable then leaving the window behind another when show is called but maybe there are other unintended consequences.

I have to admit I find this functionality incredibly annoying on OSX too, so I'd definitely like to see something like this be possible - just depends on whether there is a good reason to keep it opening behind as is currently does, at which point I think we could make it configurable. Otherwise, 👍 for altogether changing the behaviour.

IIRC, there was discussion about all of this way back when. In particular,
what I remember were issues with the figure window stealing focus when in
interactive mode. Users typing commands and building up a figure had to
keep bringing the focus back to the terminal window. There was a concerted
effort for v1.0 and v1.1 to normalize all show() behaviors across all
backends, so if someone wants to go diving through the mailing list
archives for those discussions, that might be fruitful.

We should get this sorted out before 1.4, could someone who was around for these discussions take this on?

@mdehoon @efiring @pelson @jenshnielsen As the mac-devs, can you all make a go/no-go on this PR?

The two aspects of behavior--window pops up in front or in back, and with or without focus--ideally should be controllable on all backends. I suspect this can be done, but we probably don't have the developer resources to get it done right, and all at once. In the absence of that, making some piecemeal changes like this might be better than nothing, even though I don't like having different behavior in the different backends.
There are definitely times and circumstances when having windows pop up on top of whatever one is typing is a real pain; it was quite a problem in my Matlab days, and all the more so because Matlab did not have a simple way of writing figures out to files without generating a plot window.
At the same time, working interactively with mpl and having the window always be drawn behind other windows is also a pain, and I suspect that at present this is more of a problem for more people than the opposite problem is.
Summary: I am mildly in favor of merging this, and generating a TODO issue for making the behavior selectable in all backends, to the extent possible on the various platforms.

I am also in favor of merging.

I'll take the plunge and merge then.