iframe-proxy

immaxchen · 2019-10-18T16:31:23Z

PR Summary

Address Issue #8692

A new rcParms entry have been added: "figure.raise_window"
Now it is possible to disable the default "raise GUI window" behavior
This change apply to & tested on Qt4, Qt5, Gtk3, Tk and Wx backends (OS: CentOS7, Win7)
Has document it in the 'whats new' section

Known Issue:
~~Gtk3 have to use a small trick to force the screen update, better solutions welcome~~
Qt4 "raise window" pop-out "Figure is ready", have to click the notification manually

Side Note:
Wx backend didn't implement the "raise window" behavior before
Don't have a Mac to work on macosx backend
Manually tested with the attached python script

test_raise_window.txt

PR Checklist

Has Pytest style unit tests
Code is Flake 8 compliant
New features are documented, with examples if plot related
Documentation is sphinx and numpydoc compliant
Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

immaxchen · 2019-10-19T17:20:23Z

immaxchen · 2019-10-23T13:44:03Z

Also tested on Windows7, working as expected.

timhoffm

Thanks! Looks good apart from the what's new message 👍.

Could you sqash your commits if possible? - Otherwise we'll do it before merging.

timhoffm · 2019-10-23T22:06:11Z

+A new rcParms entry have been added: with the ``figure.raise_window`` option 
+now it is possible to disable the default "raise GUI window" behavior when 
+calling ``plt.show`` or ``plt.pause`` methods.


The new config option rcParams['figure.raise_window'] allows to disable
raising the plot window when calling plt.show or plt.pause methods.

Should be sufficient and more straight forward.

… (Qt,Gtk,Tk,Wx) A new rcParms entry have been added: "figure.raise_window" Now it is possible to disable the default "raise GUI window" behavior This change apply to & tested on Qt, Gtk, Tk and Wx backends (CentOS7 & Win7) Has document it in the 'whats new' section

immaxchen · 2019-10-24T13:28:04Z

Great thanks for the help on the message, i'm not a native speaker. 😂
Have tried to rebase it, am i doing it right?

timhoffm

Rebase is correct 👍

What do you mean by: Qt4 "raise window" pop-out "Figure is ready", have to click the notification manually.

timhoffm · 2019-10-24T20:23:14Z

        # show the figure window
        self.window.show()
-        self.window.present()
+        self.canvas.draw()


Why does GTK3 need a draw now?

When I am testing with Gtk3 and turn off the "raise window", I encountered a strange behavior, that the GUI window is reluctant to update, and the whole program get stuck, loop is not running, until I move/switch the GUI window or moving my mouse cursor on the canvas, it can continue to run/update.
After debug and tracing, I found the program is stuck inside the Gtk.main_iteration() here:

def flush_events(self): # docstring inherited Gdk.threads_enter() while Gtk.events_pending(): Gtk.main_iteration() Gdk.flush() Gdk.threads_leave()

By looking into the doc, it says if there is no event queued, main_iteration will block until the next event is noticed, but that's very strange since we have already checked with events_pending, if there is no event it should not go into the while-loop. Nevertheless, I changed using Gtk.gtk_main_iteration_do(False) which the doc states that it won't block, however, that's not working, the program still get stuck inside gtk_main_iteration_do. Finally, I come up with a solution: to call window.queue_draw() right after window.show() and successfully I don't have to waving my mouse cursor over the canvas any more. And I found that this is exactly what canvas.draw() is doing, and the same approach is also used in the backend_wx.py, so I suppose this is the right way to do it? I am not familiar with the GUI stuff so I have no idea what's happening, please feel free to correct me.
This is the full report, HaHa!! Thank you so much for your patience reading this mumbo jumbo!! 😜

Could you test with draw_idle instead?

tested, won't update, need stick to draw

immaxchen · 2019-10-25T14:31:33Z

This is what I saw when I'm testing on my machine using pyqt=4 (cannot actually "raise" to top automatically, instead, have to click on the notification to bring up the window)
But using qt5 can actually bring the window to the top as expected

timhoffm · 2019-10-26T13:49:07Z

So instead of the window, a "Figure 1 is ready" message is popping to the front?

immaxchen · 2019-10-26T14:29:10Z

Yes! and it is exactly the one shown in the top-right corner of my attached image.

timhoffm · 2019-10-26T19:46:26Z

Hm, I don't find any related "... is ready" text in our code base. So who is generating that message? You are seeing this only in Qt4, not Qt5, and you are on master?

QuLogic · 2019-10-27T01:00:39Z

The message is triggered by your window manager, which isn't allowing focus stealing.

immaxchen · 2019-10-27T02:26:31Z

Yes! only in Qt4, not Qt5, and on master.
It is not generated by mpl, it's a Gnome thing (related post: here and here)
But don't know why only Qt4 is suffering this.

timhoffm · 2019-10-27T07:25:04Z

Given that Qt4 is end of life and major distributions are defaulting to Qt5, I wouldn‘t wollt too much if we can‘t get this fixed for Qt4.

immaxchen · 2019-10-28T15:22:46Z

Sure, so is there anything else I need to do?

timhoffm · 2019-10-29T06:20:07Z

I don‘t think so. I still want to take a closer look at the GTK redraw.

immaxchen · 2019-10-30T13:45:03Z

OK, thanks!

anntzer · 2019-12-07T12:59:56Z

In general this looks nice.
How does this interact with rcParams["tk.window_focus"]? If they are overlapping in functionality should tk.window_focus be deprecated?

efiring · 2019-12-10T02:44:12Z

This looks very helpful (based on a quick scan).

One thought occurs to me: would it make sense to have this controlled by an optional keyword argument to plt.show? That way it could be controlled locally instead of only globally. It would require adding the keyword argument to the intermediate Figure.show and each Backend.show as well. I think the setting of the default by rcParam could stay in the backends.

immaxchen · 2019-12-22T15:34:11Z

Thanks for the advice, seems reasonable to me. But they could be discussed & handled in separated issue & PR, IMHO.

carlosgmartin · 2020-01-12T19:56:38Z

Any update on this?

efiring

I think we should get this in ASAP. I don't see how it can do any real harm, and it is an important feature requiring minimal code.

anntzer · 2020-01-13T06:20:09Z

I think the whatsnew should at least mention that this doesn't work on the macos backend (which is fine); clarifying (as above) the interaction with the tk.window_focus rc would be nice as well.

efiring · 2020-01-13T07:05:11Z

@anntzer Good points. If this goes in, will you want to support the rcParam in your mplcairo backend?

anntzer · 2020-01-13T07:39:50Z

I haven't actually checked, but I'm almost certain mplcairo will work just fine with it because it just inherits the show() methods from the various backend-dependent but renderer-independent base classes (similarly, you can see that here the changes are in qt5.py wx.py etc. and not qt5agg.py/qt5cairo.py wxagg.py/wxcairo.py etc.).

immaxchen · 2020-01-27T07:12:43Z

I think this functionality is not exactly identical to the rcParams["tk.window_focus"].
According to the information from SO, the code used here only displays the window above all other windows (set attributes topmost as True), not necessarily steal the focus from another window.
On the other hand, rcParams["tk.window_focus"] tries to steal focus by using Win32 API.

immaxchen · 2020-01-27T07:36:54Z

Add this to whatsnew?

MacOSX backend is currently not supported.
To control the focus stealing behavior for Tk backends, use rcParams["tk.window_focus"] instead.

tacaswell

conditional on adding a note about OSX not being supported (or explicitly listing the backends that are supported).

immaxchen · 2020-01-28T16:18:02Z

done~

jklymak · 2020-01-28T20:32:32Z

Thanks @immaxchen

carlosgmartin · 2020-04-07T21:02:15Z

Is there a fix for OSX?

pczhang-tony · 2021-06-10T23:47:34Z

timhoffm reviewed Oct 23, 2019

View reviewed changes

immaxchen force-pushed the add-rcparams-to-control-raise-window-behavior-gh8692 branch from 5e76728 to 1b4c4ad Compare October 24, 2019 13:02

timhoffm reviewed Oct 24, 2019

View reviewed changes

dstansby added the topic: rcparams label Nov 9, 2019

prjemian mentioned this pull request Nov 20, 2019

New plot windows appear under console window aps-8id-dys/ipython-8idiuser#99

Closed

anntzer mentioned this pull request Dec 10, 2019

Make pyplot.pause not give focus to the figure window #11131

Closed

efiring approved these changes Jan 13, 2020

View reviewed changes

efiring added this to the v3.3.0 milestone Jan 13, 2020

tacaswell approved these changes Jan 27, 2020

View reviewed changes

adding a note about OSX not being supported

1c35ef0

jklymak merged commit 01e267c into matplotlib:master Jan 28, 2020

QuLogic mentioned this pull request Apr 22, 2020

matplotlib makes python lose focus #2253

Closed

oscargus mentioned this pull request Feb 28, 2022

function to raise plot window to the front? #6378

Closed

carlosgmartin mentioned this pull request Apr 27, 2022

[Bug]: figure.raise_window rcParam does not work on MacOSX backend #22915

Closed

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!

Uh oh!

Conversation

immaxchen commented Oct 18, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

PR Checklist

Uh oh!

immaxchen commented Oct 19, 2019

Uh oh!

immaxchen commented Oct 23, 2019

Uh oh!

timhoffm left a comment

Choose a reason for hiding this comment

Uh oh!

timhoffm Oct 23, 2019

Choose a reason for hiding this comment

Uh oh!

immaxchen commented Oct 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

timhoffm left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

timhoffm Oct 24, 2019

Choose a reason for hiding this comment

Uh oh!

immaxchen Oct 25, 2019

Choose a reason for hiding this comment

Uh oh!

tacaswell Jan 27, 2020

Choose a reason for hiding this comment

Uh oh!

immaxchen Jan 28, 2020

Choose a reason for hiding this comment

Uh oh!

immaxchen commented Oct 25, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

timhoffm commented Oct 26, 2019

Uh oh!

immaxchen commented Oct 26, 2019

Uh oh!

timhoffm commented Oct 26, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

QuLogic commented Oct 27, 2019

Uh oh!

immaxchen commented Oct 27, 2019

Uh oh!

timhoffm commented Oct 27, 2019

Uh oh!

immaxchen commented Oct 28, 2019

Uh oh!

timhoffm commented Oct 29, 2019

Uh oh!

immaxchen commented Oct 30, 2019

Uh oh!

anntzer commented Dec 7, 2019

Uh oh!

efiring commented Dec 10, 2019

Uh oh!

immaxchen commented Dec 22, 2019

Uh oh!

carlosgmartin commented Jan 12, 2020

Uh oh!

efiring left a comment

Choose a reason for hiding this comment

Uh oh!

anntzer commented Jan 13, 2020

Uh oh!

efiring commented Jan 13, 2020

Uh oh!

anntzer commented Jan 13, 2020

Uh oh!

immaxchen commented Jan 27, 2020

Uh oh!

immaxchen commented Oct 18, 2019 •

edited

Loading

immaxchen commented Oct 24, 2019 •

edited

Loading

timhoffm left a comment •

edited

Loading

immaxchen commented Oct 25, 2019 •

edited

Loading

timhoffm commented Oct 26, 2019 •

edited

Loading

pczhang-tony commented Jun 10, 2021 •

edited

Loading