An rcparam for controlling this behavior was added in mpl 3.3 to address this: https://matplotlib.org/stable/users/prev_whats_new/whats_new_3.3.0.html#rcparams-for-controlling-default-raise-window-behavior

Please remember that Matplotlib's user base is very wide and for ever user who definitely does not want the figure to come to the front, we have a user who definitely does! It is my understanding from all of those discussions is that any given user always wants one behavior or the other. This is a case where I think a global setting is the best option.

In general, it seems like a good idea to make semantically-distinct actions

Fair, but in practice these things are very tightly coupled.

If you want the UI to update and be "live", then you need to spin the event loop, if you want to spin the event loop you either have to run it for a fixed amount of time (which is what pause does) or manually flush the event queue. If you use draw_idle (which you should ;) ) then we defer actually rendering the figure until the UI is about to repaint (which again implies you have the event loop running). Thus "redrawing" and pausing for a bit are coupled. Further, if you are going to re-draw the figure it presumable needs to be on the screen so someone can see, thus showing the figure (and hence deciding if it should get focus or not) is coupled.

The connection to pause here is a bit of a red-herring, I think the core issue is what does it mean to "show" a Figure? In some cases you meant "Put in on the screen and focus it...why on earth would anyone want to go hunting for the figure they just asked to show!?" and in other cases "Yes, make it available, but I am doing other stuff while this runs in the background .. please stop stealing my focus, why on earth would anyone want that behavior?!"

also xref #8246

@tacaswell Thank you for your reply.

for ever user who definitely does not want the figure to come to the front, we have a user who definitely does!

Is there any evidence that the latter are as numerous as the former?

This is a case where I think a global setting is the best option.

Still, its default value should match the most commonly desired behavior.

if you are going to re-draw the figure it presumable needs to be on the screen so someone can see, thus showing the figure (and hence deciding if it should get focus or not) is coupled.

I don't recall using any other application that forces its window to the front every time something gets redrawn.

The connection to pause here is a bit of a red-herring, I think the core issue is what does it mean to "show" a Figure?

I don't think it's a red-herring. To quote #596 (comment):

there is nothing in the semantics of the word pause which implies that something should be brought to the front. This may be different with the word show, but pause definitely should not be doing this. This is a buggy behavior.

I have a practical question on this. I did something like

import numpy as np
import matplotlib.pyplot as plt

print(plt.rcParams["backend"])
rng = np.random.default_rng()

for _ in range(100):
    val = rng.uniform()
    plt.plot([0, val])
    plt.pause(0.1)

If I decide I don't want to watch to the end, how do I kill it? If I close the plot window, another one pops up with the next pass through the loop. I can't get back to the terminal because the plot window keeps stealing focus.

I'm on RHEL7 using QtAgg backend. The behaviour seems to be the same whether I do this in interactive mode or run a script.

I suppose there is no way to stop this due to the particular setup and interaction of a python loop and the gui event loop. Personally, I consider pause() as quite a makeshift solution that has it's limitations here.

If you wanted to do something about it, you'll likely need pause to return a flag whether the user wants to exit so that you can do something

for _ in range(100):
    ...
    stop = pause(0.1)
    if stop:
        break

but it's non trivial how to determine the signal inside pause(): There may be 0 to arbitrary many open figures. Do you stop if one gets closed or if all get closed? Maybe you can catch a global key press! But that needs special implementation in the backend.

If you make it slower:

import numpy as np
import matplotlib.pyplot as plt

print(plt.rcParams["backend"])
rng = np.random.default_rng()

for _ in range(1000):
    val = rng.uniform()
    plt.plot([0, val])
    try:
        plt.pause(2)
    except KeyboardInterrupt:
        break

you can capture a ctrl-C as an exit command (but at least on my system ctrl-c with the GUI focused does not got forwarded to Python (which I thought it should have...).

Putting this together with https://matplotlib.org/stable/users/explain/interactive_guide.html#blocking-the-prompt

import threading
import numpy as np
import matplotlib.pyplot as plt

print(plt.rcParams["backend"])
rng = np.random.default_rng()

fig, ax = plt.subplots()
ev = threading.Event()
fig.canvas.mpl_connect('close_event', lambda *args: ev.set())
plt.show(block=False)
for _ in range(1000):
    val = rng.uniform()
    ax.plot([0, val])
    fig.canvas.draw_idle()
    fig.canvas.start_event_loop(.1)
    if ev.is_set():
        break 

Wow, thanks for the detailed replies! These solutions do require the user to anticipate the problem ahead of time though (as does simply setting rcParams["figure.raise_window"] = False). Worst case scenario is someone [accidentally] creates a long-running animation that they can't get rid of without a reboot. Though I guess they would only make the mistake once...

We go through a whole bunch of effort with the Qt backends to correctly handle signals:

This does turn sigints into quitting the event loop and raising KeyboardInterput (I verified it worked by running @rcomer 's code in one terminal and sleep 5; kill -s INT <pid> in another).

tk seems to not steal focus the same way qt does, but sigint does not quit the loop. However sigint + closing the window does escape

wx also steals focus, but an exnternal sigint gets a KeyboardItnerupt

gtk also steals focus, but an external sigint gets a KeyboardInterupt

Maybe the solution here is to by default hook up a key-binding that translates ctrl-C into sending sigint to our selves? That would atleast provide an out from the denial of service attack a hot-loop-around-pause (short of sshing in from another machine or a reboot).

diff --git a/lib/matplotlib/backend_bases.py b/lib/matplotlib/backend_bases.py
index 7100f2ed34..2fbd1888a1 100644
--- a/lib/matplotlib/backend_bases.py
+++ b/lib/matplotlib/backend_bases.py
@@ -2596,6 +2596,10 @@ def key_press_handler(event, canvas=None, toolbar=None):
     toggle_yscale_keys = rcParams['keymap.yscale']
     toggle_xscale_keys = rcParams['keymap.xscale']

+    if event.key == 'ctrl+c':
+        import signal
+        signal.raise_signal(signal.SIGINT)
+
     # toggle fullscreen mode ('f', 'ctrl + f')
     if event.key in fullscreen_keys:
         try:

is enough, however

wx also steals focus, but an exnternal sigint gets a KeyboardItnerupt

gtk also steals focus, but an external sigint gets a KeyboardInterupt

Maybe the solution here is to by default hook up a key-binding that translates ctrl-C into sending sigint to our selves? That would atleast provide an out from the denial of service attack a hot-loop-around-pause (short of sshing in from another machine or a reboot).

But none of these are Ctrl+c to the window; they are SIGINT to the process which is Ctrl+c only in the terminal. Ctrl+c in any of the windows would do nothing.

Ctrl+C -> kill should only be wired up in the terminal. In GUIs this is a common shortcut and should not kill the figure.

How to fix this high priority bug?

UPD:

def plt_pause(interval):
    from matplotlib import _pylab_helpers
    manager = _pylab_helpers.Gcf.get_active()
    if manager is not None:
        canvas = manager.canvas
        if canvas.figure.stale:
            canvas.draw_idle()
        # show(block=False)  # <- What causes the plot to steal focus
        canvas.start_event_loop(interval)
    else:
        import time
        time.sleep(interval)

plt.pause = plt_pause

Why you discussing some Ctrl+C here?