You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If in a code you create many figures, it starts to become inconvenient because each figure creates a new window.
It would be very useful to be able to create workbook of figures organized in tabs.
Also related to #7338 in that both involve GUI backend work. In my view, #7338 is addressing a more urgent problem--not just convenience, but making the displayed and saved plot match what one has specified.
@astromancer would you consider adding that to mpl-third-party? Also, maybe could you comment here on how reasonable this was as a 3rd party library versus whether we should be working on including something like this as a tool for the main library? Our GUI work takes a significant maintenance toll if we try to keep parity between backends.
would you consider adding that to mpl-third-party?
@jklymak Happy to do add it. Do i need to open a PR to do that?
Also, maybe could you comment here on how reasonable this was as a 3rd party library
With the current implementation, this doesn't really serve as an alternative for the pyplot ui in any way. It just takes the canvas from an existing figure and puts it into a tab widget post facto. If the user creates a new figure, that is handled by pyplot in the normal way, and one has to then explicitly add this figure to the tab widget. This work as a proof of concept and was fairly easy to implement (in pyqt/pyside at least), but has some drawbacks and inefficiencies. More work will need to be done to get better interoperability with pyplot, for example getting new figures to appear automatically as new tabs etc. I have zero experience with any of the other backend toolkits, so can't say how difficult it would be to implement tabbed figure managers for those.
If the user creates a new figure, that is handled by pyplot in the normal way, and one has to then explicitly add this figure to the tab widget
The slightly weird thing about this is that in add_tab you call plt.close(fig) which (from the point of view of pyplot) orphans the figure and then you then re-embed in your tabs.
More work will need to be done to get better interoperability with pyplot, for example getting new figures to appear automatically as new tabs etc.
I'm not fully convinced that is worth doing. pyplot is really doing two things:
keeping track of implicitly creating UI objects (the QObjects) so that they do not get gc'd + showing them when needed
supporting the implicit plt.plot(...) interface and keeping track of a "current Figure" (and the figure has a "current axes").
While there are decent use-cases for 2, I think that once you get to a multi-tabbed figure like that they start to fall apart (and the implicit state management has gone from an asset that saves you from some boiler plate to a liability where there is now some critical state held some where else in the code that is near impossible to trace) and given the way you have done the API here, the user already has an explicit object (the ui) so we do not need to track that for the user.
I have some further opinions, but I'll express them in terms of a PR to mpl-multitab.
I'm surprised that people have been asking for basic tab support over ten years at this point, yet MatPlotLib maintainers for some reason refuse to offer it at all?
The same issue appears across multiple third-party programs (plotWindow by @superjax and mpl-multitab by @tacaswell), which seems to point to an underlying issue with MatPlotLib and/or implementation of MultiCursor, as mentioned here:
The problem is that the MultiCursor functionality of MatPlotLib does not work properly with tabs. Either a vertical cursor only displays on the last tab, rather than on all tabs.
If there were a generic MatPlotLib interface for dealing with tabs, this would enable all third-party programs to use that interface without needing to create individual workarounds for basic missing functionality such as tab support.
Tabbed interfaces are a universal user-interface design pattern now, so it's strange that the functionality would be completely absent in such a widely used, visual library such as MatPlotLib. The only explanation I've read so far is that... "MatPlotLib is foremost a library". And tabbed interfaces are foremost a universal means of accessing data visualized by libraries like MatPlotLib, so I would hope for the sake of everyone over the past ten years, someone can finally make MatPlotLib compatible with tabs.
The alternative is to force each third-party developer to hack their own version of tabs that has the exact problem described here: everyone has to repeatedly invent different solutions for the same problem. Solving the problem once within MatPlotLib (similar to what has already been done with MultiCursor, only for tab support) would enable everyone to build upon the existing foundation instead of reinventing solutions for design issues that are universally useful to anyone who uses MatPlotLib for anything beyond the most basic purposes.
The only explanation I've read so far is that... "MatPlotLib is foremost a library".
The full explanation is in #23328 (comment) and that tabbed interfaces are complex, and we do not have a large app development team to robustly propagate such an interface across all our operating systems and backends and then maintain it in perpetuity for the users who have grown used to using it.
we do not have a large app development team to robustly propagate such an interface across all our operating systems and backends and then maintain it in perpetuity for the users who have grown used to using it.
That is a strange overgeneralization about "all operating systems and backend... in perpetuity", when, for example, the two options discussed in this conversation (mpl-multitab and plotWindow) both use PyQt.
Supporting one Python binding of one GUI toolkit isn't exactly beyond imagination. The practical benefits of the maintainers offering one or two choices that are well-known, popular, and well-tested, far outweigh the amount of energy required to maintain the "in perpetuity", or at least for however long matplotlib exists.
There are a couple of issues here that I want to address:
First, I want to remind everyone remain professional and avoid personal attacks. All of the maintainers are working on Matplotlib in good faith, please trust us when we say something is either hard our out of scope.
Second, Jody is correct. We are committed to providing parity across the all of the GUI toolkits we support and we are committed to once we put a feature is released to keeping it working for our users going forward. If we support tabs in a first class way for one toolkit (Qt) we should support it for all (tk, wx, gtk, osx).
Third, both the API and UI on tabs are surprisingly complex (for example mpl-multitab is actually 2 mostly independent bits of code one for the 1D tabs, one for the 2D tabs). We provide a basic UI embedding (one figure to one main window) and then the underlying widgets so that application developers and embed Matplotlib in their UI however they want. I can see a couple of paths to get there in a lowest-common-denominator way, but not a good way to toggle the behavior on and off. If you have ideas on how to do this we would be happy to review a PR @goobleplax .
Forth, if we support tabs "natively" or not is unrelated to MultiCursor working between Figures (each tab is its own Figure) because that code assumes all of the Axes are in the same figure (and on the same canvas).
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
I'm going to close this. It is unlikely that we are going to bring full-tab support to the main library (in part because it is not clear what the "right" API is and if we can support it across all of the UI frameworks we support) and there exists at least one general purpose tabbing (https://github.com/astromancer/mpl-multitab ).
Activity
petehuang commentedon Jan 7, 2017
Related to MEP23? https://github.com/matplotlib/matplotlib/blob/master/doc/devel/MEP/MEP23.rst
efiring commentedon Jan 7, 2017
Also related to #7338 in that both involve GUI backend work. In my view, #7338 is addressing a more urgent problem--not just convenience, but making the displayed and saved plot match what one has specified.
astromancer commentedon Jun 10, 2022
If you use one of the qt backends, you can try use:
mpl-multitabjklymak commentedon Jun 10, 2022
@astromancer would you consider adding that to mpl-third-party? Also, maybe could you comment here on how reasonable this was as a 3rd party library versus whether we should be working on including something like this as a tool for the main library? Our GUI work takes a significant maintenance toll if we try to keep parity between backends.
astromancer commentedon Jun 14, 2022
@jklymak Happy to do add it. Do i need to open a PR to do that?
With the current implementation, this doesn't really serve as an alternative for the
pyplotui in any way. It just takes the canvas from an existing figure and puts it into a tab widget post facto. If the user creates a new figure, that is handled by pyplot in the normal way, and one has to then explicitly add this figure to the tab widget. This work as a proof of concept and was fairly easy to implement (in pyqt/pyside at least), but has some drawbacks and inefficiencies. More work will need to be done to get better interoperability withpyplot, for example getting new figures to appear automatically as new tabs etc. I have zero experience with any of the other backend toolkits, so can't say how difficult it would be to implement tabbed figure managers for those.oscargus commentedon Jun 14, 2022
Yes, please create a PR here: https://github.com/matplotlib/mpl-third-party
tacaswell commentedon Jun 15, 2022
The slightly weird thing about this is that in
add_tabyou callplt.close(fig)which (from the point of view of pyplot) orphans the figure and then you then re-embed in your tabs.I'm not fully convinced that is worth doing.
pyplotis really doing two things:QObjects) so that they do not get gc'd + showing them when neededplt.plot(...)interface and keeping track of a "current Figure" (and the figure has a "current axes").While there are decent use-cases for 2, I think that once you get to a multi-tabbed figure like that they start to fall apart (and the implicit state management has gone from an asset that saves you from some boiler plate to a liability where there is now some critical state held some where else in the code that is near impossible to trace) and given the way you have done the API here, the user already has an explicit object (the
ui) so we do not need to track that for the user.I have some further opinions, but I'll express them in terms of a PR to mpl-multitab.
tacaswell commentedon Jun 15, 2022
astromancer/mpl-multitab#2
goobleplax commentedon Jun 23, 2022
I'm surprised that people have been asking for basic tab support over ten years at this point, yet MatPlotLib maintainers for some reason refuse to offer it at all?
The same issue appears across multiple third-party programs (plotWindow by @superjax and mpl-multitab by @tacaswell), which seems to point to an underlying issue with MatPlotLib and/or implementation of MultiCursor, as mentioned here:
#23328 (comment)
The problem is that the MultiCursor functionality of MatPlotLib does not work properly with tabs. Either a vertical cursor only displays on the last tab, rather than on all tabs.
If there were a generic MatPlotLib interface for dealing with tabs, this would enable all third-party programs to use that interface without needing to create individual workarounds for basic missing functionality such as tab support.
Tabbed interfaces are a universal user-interface design pattern now, so it's strange that the functionality would be completely absent in such a widely used, visual library such as MatPlotLib. The only explanation I've read so far is that... "MatPlotLib is foremost a library". And tabbed interfaces are foremost a universal means of accessing data visualized by libraries like MatPlotLib, so I would hope for the sake of everyone over the past ten years, someone can finally make MatPlotLib compatible with tabs.
The alternative is to force each third-party developer to hack their own version of tabs that has the exact problem described here: everyone has to repeatedly invent different solutions for the same problem. Solving the problem once within MatPlotLib (similar to what has already been done with MultiCursor, only for tab support) would enable everyone to build upon the existing foundation instead of reinventing solutions for design issues that are universally useful to anyone who uses MatPlotLib for anything beyond the most basic purposes.
jklymak commentedon Jun 23, 2022
The full explanation is in #23328 (comment) and that tabbed interfaces are complex, and we do not have a large app development team to robustly propagate such an interface across all our operating systems and backends and then maintain it in perpetuity for the users who have grown used to using it.
goobleplax commentedon Jun 24, 2022
That is a strange overgeneralization about "all operating systems and backend... in perpetuity", when, for example, the two options discussed in this conversation (mpl-multitab and plotWindow) both use PyQt.
Supporting one Python binding of one GUI toolkit isn't exactly beyond imagination. The practical benefits of the maintainers offering one or two choices that are well-known, popular, and well-tested, far outweigh the amount of energy required to maintain the "in perpetuity", or at least for however long matplotlib exists.
tacaswell commentedon Jun 24, 2022
There are a couple of issues here that I want to address:
First, I want to remind everyone remain professional and avoid personal attacks. All of the maintainers are working on Matplotlib in good faith, please trust us when we say something is either hard our out of scope.
Second, Jody is correct. We are committed to providing parity across the all of the GUI toolkits we support and we are committed to once we put a feature is released to keeping it working for our users going forward. If we support tabs in a first class way for one toolkit (Qt) we should support it for all (tk, wx, gtk, osx).
Third, both the API and UI on tabs are surprisingly complex (for example mpl-multitab is actually 2 mostly independent bits of code one for the 1D tabs, one for the 2D tabs). We provide a basic UI embedding (one figure to one main window) and then the underlying widgets so that application developers and embed Matplotlib in their UI however they want. I can see a couple of paths to get there in a lowest-common-denominator way, but not a good way to toggle the behavior on and off. If you have ideas on how to do this we would be happy to review a PR @goobleplax .
Forth, if we support tabs "natively" or not is unrelated to MultiCursor working between Figures (each tab is its own Figure) because that code assumes all of the Axes are in the same figure (and on the same canvas).
anntzer commentedon Jun 5, 2023
As a side point, MultiCursor can be used across multiple figures since #23348.
github-actions commentedon Jun 5, 2024
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
tacaswell commentedon Jun 7, 2024
I'm going to close this. It is unlikely that we are going to bring full-tab support to the main library (in part because it is not clear what the "right" API is and if we can support it across all of the UI frameworks we support) and there exists at least one general purpose tabbing (https://github.com/astromancer/mpl-multitab ).
https://github.com/matplotlib/mpl-gui may make writing future tabbed windows easier in the future.