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
{{ message }}
Repository navigation
Modifying ticks in the Figure options window #1543
AFAIK it is currently not possible to modify the ticks of a plot
within the "Figure options" window. Is it planned to add this feature
to the "Figure options" window ?
Yes, I think the Figure Options window exists only for the Qt backend. Personally, I think it may have been a mistake to add it at all; unlike the subplots gui, it doesn't strike me as a very useful tool for working with a plot. I'm going to close this with my opinion that no, we do not plan to add tick modification as an option to that window. This does not in any way prevent someone from submitting a PR to do so, of course.
I disagree it was a mistake, I think it is one of the more compelling reasons to use the qt backends over the others. Anecdotally, users at my day-job love it!
@anntzer has been working on that window quite a bit (I assume mostly scratching itches).
I personally think it is extraordinarily useful to be able to interactively modify a plot after it has been made -- either because you don't want to re-run a slow-ish script, or because you are (perhaps as @tacaswell mentions) distributing your code for use by non-programmers.
I don't think making the tickers settable via the UI is an unreasonable request (at least it should be possible to set it to a FixedFormatter), so I'm going to reopen this.
Note that in order to provide the Figure Options UI for other backends, one "only" needs to reimplement the formlayout API (which abstracts away the Qt layer). If some GTK/Tk expert is interested in reimplementing such an abstraction layer for another toolkit, I can also share another similar API that I have written for personal use (currently Qt-only too), which I personally prefer :-).
Indeed, I gave it a try and it looks very nice. @newville, would you be interested in working together on unifying as much as possible the Qt and Wx interfaces and implementations?
@anntzer Yeah, I think that would be great! I'm not fluent in Qt, but I'm willing to learn it better. Wxmplot tries to use matplotlib as much as possible (say, for event handling) so that, aside from the obvious GUI forms, there isn't really that much wx-specific code. It's also old enough (much of it predates matplotlib 1.0) that some parts of the "plot configuration" could almost certainly be done better.
Anyway, I think making a library like this for both Qt and Wx (and possibly part of matplotlib?) would be really useful for many matplotlib users.
Great! I'm a bit busy with many things right now but I'll try to list what wxmplot offers (I assume the examples cover all the functionalities?) and see how it can be integrated with the existing codebase or whether we should start something from scratch integrating the capabilities of the current Qt interface and of wxmplot.
It looks like a few features from wxmplot can easily be adapted into the Qt editor: exposing artist zorder, toggling the legend (I think making the legend "active" for toggling artist visibility is better provided as a callback recipe), changing the image normalization class.
A few other features are already present (in 2.0): changing image smoothing and changing image normalization bounds.
I don't think auto-contrasting is suitable for the core library.
@newville Can you have a look at guidata (https://pythonhosted.org/guidata/examples.html#basic-example)? Do you think it would be reasonable to base a new matplotlib UI on it and let you or others add a wx compatibility layer? (If you know a similar package that is based on wx I can look into adding a Qt compatibility layer as well, of course.)
On Wed, Jan 4, 2017 at 12:12 PM, Antony Lee ***@***.***> wrote:
@newville <https://github.com/newville> Can you have a look at guidata (
https://pythonhosted.org/guidata/examples.html#basic-example)? Do you
think it would be reasonable to base a new matplotlib UI on it and let you
or others add a wx compatibility layer? (If you know a similar package that
is based on wx I can look into adding a Qt compatibility layer as well, of
course.)
I'm still trying to understand your message from 2 or 3 days ago. Sorry,
but I am not familiar with the Qt backend, nor very familiar with
matplotlib 2. I'm not sure why would changing image smoothing and
normalization bounds would be OK (perhaps already included?) while allowing
auto-contrast would be unsuitable. Why is that?
The guidata library looks nice, but seems to be Qt only - is that
correct? Traits is sort of similar, depending on what you're looking for,
and I believe it supports both Qt and wx.
I think it would useful to figure out what the goals are first. What is
desirable for better matplotlib backend GUI(s)? I may have come in late to
this conversation or missed other conversations about what is being done on
the Qt backend. Can you give me an overview of what you'd like to see?
I'm still trying to understand your message from 2 or 3 days ago. Sorry,
but I am not familiar with the Qt backend, nor very familiar with
matplotlib 2. I'm not sure why would changing image smoothing and
normalization bounds would be OK (perhaps already included?) while allowing
auto-contrast would be unsuitable. Why is that?
Because the first two directly map to methods or attributes on the image class (or its attributes), whereas the last one involves data-specific "logic", which I'd rather avoid (if you manage to convince the core devs that the image class needs an auto_contrast method (which I'd disagree) then it can go to the UI as well of course).
The guidata library looks nice, but seems to be Qt only - is that
correct? Traits is sort of similar, depending on what you're looking for,
and I believe it supports both Qt and wx.
traitsui would indeed be an alternative, but it is a much bigger dependency to pull in (as a comparison point, formlayout (https://github.com/PierreRaybaut/formlayout), which is currently the basis of the Qt figure options, is a single file). @tacaswell@Tillsten (who participated in the gitter discussion) Thoughts?
I think it would useful to figure out what the goals are first. What is
desirable for better matplotlib backend GUI(s)? I may have come in late to
this conversation or missed other conversations about what is being done on
the Qt backend. Can you give me an overview of what you'd like to see?
These are screenshots of what the Qt backend currently provides:
While being slightly verbose the simplest solution would be properly to write such a dialogue directly in the other toolkits, as dialog itself is not very complicated and its only real interaction is to apply settings, something which can be resused. Mpl also does not have to promise feature equivalence between the gui-backends. Traits(ui) is definitely too big of a dependency.
On Thu, Jan 5, 2017 at 6:10 AM, Antony Lee ***@***.***> wrote:
I'm still trying to understand your message from 2 or 3 days ago. Sorry,
but I am not familiar with the Qt backend, nor very familiar with
matplotlib 2. I'm not sure why would changing image smoothing and
normalization bounds would be OK (perhaps already included?) while allowing
auto-contrast would be unsuitable. Why is that?
Because the first two directly map to methods or attributes on the image
class (or its attributes), whereas the last one involves data-specific
"logic", which I'd rather avoid (if you manage to convince the core devs
that the image class needs an auto_contrast method (which I'd disagree)
then it can go to the UI as well of course).
My view is that a UI should provide ways for the user to interact with the
data, not be restricted to map onto what an API provides. FWIW, I think the
AxesImage class does not need an auto_contrast() method but only because it
is a trivial (one-line) operation.
I do not share the desire to avoid data-specific methods in the API.
Wxmplot definitely allows adjusting the display thresholds for images,
including sliders to set the min/max values, defaulting to the **data**
range. If the UI already provides a way for the user to set upper/lower
display levels, why not also have methods to help the user do this? All
"auto contrast" does is set the display min/max to
`np.percentile(image_data, [p, 100-p])` where p defaults to 1.0. It's a
pretty common technique, and for much of the data I deal with, it makes a
big difference.
It's OK with me if you don't want to provide it in the Qt GUI, but calling
it unsuitable because it is data-specific seems really odd to me. I think
data-specific is kind of the point.
The guidata library looks nice, but seems to be Qt only - is that
correct? Traits is sort of similar, depending on what you're looking for,
and I believe it supports both Qt and wx.
traitsui would indeed be an alternative, but it is a much bigger
dependency to pull in (as a comparison point, formlayout (
https://github.com/PierreRaybaut/formlayout), which is currently the
basis of the Qt figure options, is a single file). @tacaswell
<https://github.com/tacaswell> @Tillsten <https://github.com/Tillsten>
(who participated in the gitter discussion) Thoughts?
Hm. You brought up guidata and asked for comparisons based of features. I
tried to answer. You responded about a completely separate consideration -
some notion of "dependency size". Then, in order to argue about this newly
important attribute (size), you discuss a different library because it is
apparently better (smaller). Sorry, but two textbook fallacies at one time
is too much for me.
I do not know if traitsui is a "bigger dependency" than guidata. What is
dependency size anyway? Unless I'm in the wrong conversation, we're talking
about supporting both Qt and wxPython in matplotlib.
Anyway, I don't have a preference for which additional libraries might be
used. I'm still trying to figure out "what", not "how". But this part of
the conversation has definitely dampened my enthusiasm.
I think it would useful to figure out what the goals are first. What is
desirable for better matplotlib backend GUI(s)? I may have come in late to
this conversation or missed other conversations about what is being done on
the Qt backend. Can you give me an overview of what you'd like to see?
These are screenshots of what the Qt backend currently provides:
OK, thanks for the screenshots. At least I have an idea what the Qt GUI
form provides.
But. what are the goals for what a user interface *should* include?
I think it would be useful for matplotlib to provide better UIs that helped
users customize and interact with data after it is shown. I think that 2D
line plotting as from pyplot.plot() is probably close to 50% of the use of
matplotlib, so maybe we could think about better ways to interact with and
customize these relatively simple plots. GUI forms for configuring axis
labels, titles, colors, and basic Line2D properties (label, color,
linewidth, marker, zorder) might be sufficient, or at least a good start.
There is probably a fair amount of GUI-independent "configuration/control"
code that could be shared to tie the matplotlib API calls to different GUI
toolkits. It might take a few iterations to work out what that code
should be, but it might also make for more uniform and richly-featured GUIs
for several of the backends.
Wxmplot has a config.PlotConfig class might be a good place to start. It
is old, not well documented, and might want some updating, but I think most
of it is pretty clear, and it does not use wx at all. For image
config/control, there is also an imageconf.ImageConfig class. Again, I'm
not I saying that any of these should be used, but they might be a good
start of the discussion of what is desirable.
It might also be useful to think about cursor/mouse interaction, but
perhaps that's for later discussion. I'm still trying to understand what
the goal is, and whether this is something that I have energy for.
I do not share the desire to avoid data-specific methods in the API.
Wxmplot definitely allows adjusting the display thresholds for images,
including sliders to set the min/max values, defaulting to the data
range. If the UI already provides a way for the user to set upper/lower
display levels, why not also have methods to help the user do this? All
"auto contrast" does is set the display min/max to np.percentile(image_data, [p, 100-p]) where p defaults to 1.0. It's a
pretty common technique, and for much of the data I deal with, it makes a
big difference.
This subsumes into the question of what the goals of this work are. My point of view is simply that matplotlib currently ships by default a much better config UI for the Qt backends than for the other backends, so it would be nice if the other backends could share the same UI. Yes, it may even be better if all backends could share an even better UI, but the one that Qt has is already widely used, so I would say that its features have shown themselves useful.
Hm. You brought up guidata and asked for comparisons based of features. I
tried to answer. You responded about a completely separate consideration -
some notion of "dependency size". Then, in order to argue about this newly
important attribute (size), you discuss a different library because it is
apparently better (smaller). Sorry, but two textbook fallacies at one time
is too much for me.
I do not know if traitsui is a "bigger dependency" than guidata. What is
dependency size anyway? Unless I'm in the wrong conversation, we're talking
about supporting both Qt and wxPython in matplotlib.
Anyway, I don't have a preference for which additional libraries might be
used. I'm still trying to figure out "what", not "how". But this part of
the conversation has definitely dampened my enthusiasm.
I do not see why you would want to take this personally, as my considerations are purely technical. formlayout, on which the Qt config dialog is currently based, is ~500 lines of pure Python, although it only supports one backend. I would say that adding a dependendency on 60,000 lines of Python and 4,000 lines of C (traits+traitsui) for supporting a second backend (not even all the interactive backends!) is quite a lot when all the use that will be made of it is to generate a config dialog.
In fact I now tend to agree with @Tillsten's suggestion that it will probably be easier to just write the dialogs by hand.
I think it would be useful for matplotlib to provide better UIs that helped
users customize and interact with data after it is shown. I think that 2D
line plotting as from pyplot.plot() is probably close to 50% of the use of
matplotlib, so maybe we could think about better ways to interact with and
customize these relatively simple plots. GUI forms for configuring axis
labels, titles, colors, and basic Line2D properties (label, color,
linewidth, marker, zorder) might be sufficient, or at least a good start.
There is probably a fair amount of GUI-independent "configuration/control"
code that could be shared to tie the matplotlib API calls to different GUI
toolkits. It might take a few iterations to work out what that code
should be, but it might also make for more uniform and richly-featured GUIs
for several of the backends.
As you can see, everything you mention is already there in the Qt dialog, with the exception of zorder, which could easily be added. As far as I can see they are also there in wxmplot, but with a somewhat different interface.
Legend location could also be added.
It might also be useful to think about cursor/mouse interaction, but
perhaps that's for later discussion. I'm still trying to understand what
the goal is, and whether this is something that I have energy for.
On Sat, Jan 7, 2017 at 2:23 AM, Antony Lee ***@***.***> wrote:
I do not share the desire to avoid data-specific methods in the API.
Wxmplot definitely allows adjusting the display thresholds for images,
including sliders to set the min/max values, defaulting to the *data*
range. If the UI already provides a way for the user to set upper/lower
display levels, why not also have methods to help the user do this? All
"auto contrast" does is set the display min/max to
np.percentile(image_data, [p, 100-p]) where p defaults to 1.0. It's a
pretty common technique, and for much of the data I deal with, it makes a
big difference.
This subsumes into the question of what the goals of this work are.
Very sorry for the delay.
I would think having the UI settings be data-aware (for example, knowing
data ranges) would be obvious. You said earlier that you wanted to avoid
data-specific logic, which I found somewhat surprising. Auto-contrast
is definitely data-specific logic -- a way to set the intensity range for
an image. If you allow the user to set thresholds and there is a simple
method that would fill in those values for them, why not allow that? It
seemed like you were saying you would disallow such a method **solely
because** it investigated the data being displayed.
My point of view is simply that matplotlib currently ships by default a
much better config UI for the Qt backends than for the other backends, so
it would be nice if the other backends could share the same UI. Yes, it may
even be better if all backends could share an even better UI, but the one
that Qt has is already widely used, so I would say that its features have
shown themselves useful.
OK. Do you think the Qt UI should simply be ported to other backends? You
might embrace this as an opportunity to learn how other people have
approached the problem, and possibly come up with an easier way to support
multiple backends. That would appear to be in the spirit of matplotlib.
Hm. You brought up guidata and asked for comparisons based of features. I
tried to answer. You responded about a completely separate consideration -
some notion of "dependency size". Then, in order to argue about this newly
important attribute (size), you discuss a different library because it is
apparently better (smaller). Sorry, but two textbook fallacies at one time
is too much for me.
I do not know if traitsui is a "bigger dependency" than guidata. What is
dependency size anyway? Unless I'm in the wrong conversation, we're talking
about supporting both Qt and wxPython in matplotlib.
Anyway, I don't have a preference for which additional libraries might be
used. I'm still trying to figure out "what", not "how". But this part of
the conversation has definitely dampened my enthusiasm.
I do not see why you would want to take this personally, as my
considerations are purely technical.
Uh, well, sorry if I gave the impression that I took it personally -- I did
not and do not. Of course, I do chose who I work with. You asked about
packages, I took the time to answer. If you now do not want to use other
package, that's fine with me. I never suggested otherwise, and have
neither a strong opinion for or against using any other tools.
formlayout, on which the Qt config dialog is currently based, is ~500
lines of pure Python, although it only supports one backend. I would say
that adding a dependendency on 60,000 lines of Python and 4,000 lines of C
(traits+traitsui) for supporting a second backend (not even all the
interactive backends!) is quite a lot when all the use that will be made of
it is to generate a config dialog.
Umm, it's a week later, and I still have to ask: Who cares? Don't you do
"pip install" or whatever? Are you trying to convince me that dependencies
have a "size" and that size (in lines of source code) makes that dependency
worse? I am not persuaded by any part of that argument. That said, I
write lots of GUI code, and do not use Traits.
Also: you didn't ask about "formlayout" but "guidata". I'd never heard of
either.
In fact I now tend to agree with @Tillsten <https://github.com/Tillsten>'s
suggestion that it will probably be easier to just write the dialogs by
hand.
I think it would be useful for matplotlib to provide better UIs that helped
users customize and interact with data after it is shown. I think that 2D
line plotting as from pyplot.plot() is probably close to 50% of the use of
matplotlib, so maybe we could think about better ways to interact with and
customize these relatively simple plots. GUI forms for configuring axis
labels, titles, colors, and basic Line2D properties (label, color,
linewidth, marker, zorder) might be sufficient, or at least a good start.
There is probably a fair amount of GUI-independent "configuration/control"
code that could be shared to tie the matplotlib API calls to different GUI
toolkits. It might take a few iterations to work out what that code
should be, but it might also make for more uniform and richly-featured GUIs
for several of the backends.
As you can see, everything you mention is already there in the Qt dialog,
with the exception of zorder, which could easily be added. As far as I can
see they are also there in wxmplot, but with a somewhat different interface.
OK, so much of the simplest functionality is currently similar. I'd be
interested to hear what you would you like to see happen for a general
solution.
Legend location could also be added.
It might also be useful to think about cursor/mouse interaction, but
perhaps that's for later discussion. I'm still trying to understand what
the goal is, and whether this is something that I have energy for.
You may want to have a look at https://github.com/joferkingto
n/mpldatacursor or (self-plug) https://mplcursors.readthedocs
.io/en/stable/ (specifically https://mplcursors.readthedocs
.io/en/stable/#activation-by-environment-variable).
That would be -1 from me. Wxmplot's PlotFrame reports the lve X,Y
coordinates, like a "regular" mpl plot window, and is always ready for
"zoom to rectangle" (with multiple levels of unzoom). We did recently add
the neat trick of being able to click on a legend to hide/show the display
of the corresponding line. But, clicking or moving the mouse over a line
trace to display any extra info (which is what I understand this
mpldatacursor to do) seems superfluous to me.
Anyway, I'm still in favor of having more interactive backends, but I doubt
that I will have much time to work on this myself.
Cheers,
OK. Do you think the Qt UI should simply be ported to other backends? You
might embrace this as an opportunity to learn how other people have
approached the problem, and possibly come up with an easier way to support
multiple backends. That would appear to be in the spirit of matplotlib.
I would certainly think that the current Qt UI is at least a common
denominator. If other backends reach the same level of support we can then
talk about even more complex, possibly data aware UIs.
Umm, it's a week later, and I still have to ask: Who cares? Don't you do
"pip install" or whatever? Are you trying to convince me that dependencies
have a "size" and that size (in lines of source code) makes that dependency
worse? I am not persuaded by any part of that argument. That said, I
write lots of GUI code, and do not use Traits.
If you are not convinced by the size, another argument is that (as far as I
can tell) traits can indeed *not* be pip installed at least in the absence
of a C compiler, which is pretty common on Windows (traits has no wheels on
pypi, and includes a compiled component).
Also: you didn't ask about "formlayout" but "guidata". I'd never heard of
either.
formlayout is what is currently used, guidata is what I'd rather use
instead.
OK, so much of the simplest functionality is currently similar. I'd be
interested to hear what you would you like to see happen for a general
solution.
Factor out the GUI-dependent code and let the backends share the
GUI-independent part, as much as possible. For example, a possible design
would be to have a single callable entry point for each backend, which
takes as argument (say) a nested (ordered) dictionary (or class instance)
specifying the editable artists, and calling back a common function with
the same dictionary but modified with the user input.
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!
Activity
petehuang commentedon Dec 31, 2016
Is this specific to one type of backend? Qt?
efiring commentedon Dec 31, 2016
Yes, I think the Figure Options window exists only for the Qt backend. Personally, I think it may have been a mistake to add it at all; unlike the subplots gui, it doesn't strike me as a very useful tool for working with a plot. I'm going to close this with my opinion that no, we do not plan to add tick modification as an option to that window. This does not in any way prevent someone from submitting a PR to do so, of course.
tacaswell commentedon Dec 31, 2016
I disagree it was a mistake, I think it is one of the more compelling reasons to use the qt backends over the others. Anecdotally, users at my day-job love it!
@anntzer has been working on that window quite a bit (I assume mostly scratching itches).
anntzer commentedon Dec 31, 2016
I personally think it is extraordinarily useful to be able to interactively modify a plot after it has been made -- either because you don't want to re-run a slow-ish script, or because you are (perhaps as @tacaswell mentions) distributing your code for use by non-programmers.
I don't think making the tickers settable via the UI is an unreasonable request (at least it should be possible to set it to a FixedFormatter), so I'm going to reopen this.
Note that in order to provide the Figure Options UI for other backends, one "only" needs to reimplement the formlayout API (which abstracts away the Qt layer). If some GTK/Tk expert is interested in reimplementing such an abstraction layer for another toolkit, I can also share another similar API that I have written for personal use (currently Qt-only too), which I personally prefer :-).
tacaswell commentedon Dec 31, 2016
@newville has implemented something similar in wx (https://newville.github.io/wxmplot/).
anntzer commentedon Jan 1, 2017
Indeed, I gave it a try and it looks very nice. @newville, would you be interested in working together on unifying as much as possible the Qt and Wx interfaces and implementations?
newville commentedon Jan 1, 2017
@anntzer Yeah, I think that would be great! I'm not fluent in Qt, but I'm willing to learn it better. Wxmplot tries to use matplotlib as much as possible (say, for event handling) so that, aside from the obvious GUI forms, there isn't really that much wx-specific code. It's also old enough (much of it predates matplotlib 1.0) that some parts of the "plot configuration" could almost certainly be done better.
Anyway, I think making a library like this for both Qt and Wx (and possibly part of matplotlib?) would be really useful for many matplotlib users.
anntzer commentedon Jan 1, 2017
Great! I'm a bit busy with many things right now but I'll try to list what wxmplot offers (I assume the examples cover all the functionalities?) and see how it can be integrated with the existing codebase or whether we should start something from scratch integrating the capabilities of the current Qt interface and of wxmplot.
anntzer commentedon Jan 3, 2017
It looks like a few features from wxmplot can easily be adapted into the Qt editor: exposing artist zorder, toggling the legend (I think making the legend "active" for toggling artist visibility is better provided as a callback recipe), changing the image normalization class.
A few other features are already present (in 2.0): changing image smoothing and changing image normalization bounds.
I don't think auto-contrasting is suitable for the core library.
Anything else I'm missing?
newville commentedon Jan 3, 2017
@anntzer I should probably look into what the Qt editor does.
When you say "present (in 2.0)", do you mean in matplotlib itself or exposed easily through a GUI to the end-user?
anntzer commentedon Jan 3, 2017
The Qt5 backend provides this GUI by default.
anntzer commentedon Jan 4, 2017
@newville Can you have a look at guidata (https://pythonhosted.org/guidata/examples.html#basic-example)? Do you think it would be reasonable to base a new matplotlib UI on it and let you or others add a wx compatibility layer? (If you know a similar package that is based on wx I can look into adding a Qt compatibility layer as well, of course.)
newville commentedon Jan 4, 2017
anntzer commentedon Jan 5, 2017
Because the first two directly map to methods or attributes on the image class (or its attributes), whereas the last one involves data-specific "logic", which I'd rather avoid (if you manage to convince the core devs that the image class needs an
auto_contrastmethod (which I'd disagree) then it can go to the UI as well of course).traitsui would indeed be an alternative, but it is a much bigger dependency to pull in (as a comparison point, formlayout (https://github.com/PierreRaybaut/formlayout), which is currently the basis of the Qt figure options, is a single file). @tacaswell @Tillsten (who participated in the gitter discussion) Thoughts?
These are screenshots of what the Qt backend currently provides:
Tillsten commentedon Jan 5, 2017
While being slightly verbose the simplest solution would be properly to write such a dialogue directly in the other toolkits, as dialog itself is not very complicated and its only real interaction is to apply settings, something which can be resused. Mpl also does not have to promise feature equivalence between the gui-backends. Traits(ui) is definitely too big of a dependency.
newville commentedon Jan 6, 2017
anntzer commentedon Jan 7, 2017
This subsumes into the question of what the goals of this work are. My point of view is simply that matplotlib currently ships by default a much better config UI for the Qt backends than for the other backends, so it would be nice if the other backends could share the same UI. Yes, it may even be better if all backends could share an even better UI, but the one that Qt has is already widely used, so I would say that its features have shown themselves useful.
I do not see why you would want to take this personally, as my considerations are purely technical.
formlayout, on which the Qt config dialog is currently based, is ~500 lines of pure Python, although it only supports one backend. I would say that adding a dependendency on 60,000 lines of Python and 4,000 lines of C (traits+traitsui) for supporting a second backend (not even all the interactive backends!) is quite a lot when all the use that will be made of it is to generate a config dialog.In fact I now tend to agree with @Tillsten's suggestion that it will probably be easier to just write the dialogs by hand.
As you can see, everything you mention is already there in the Qt dialog, with the exception of zorder, which could easily be added. As far as I can see they are also there in wxmplot, but with a somewhat different interface.
Legend location could also be added.
You may want to have a look at https://github.com/joferkington/mpldatacursor or (self-plug) https://mplcursors.readthedocs.io/en/stable/ (specifically https://mplcursors.readthedocs.io/en/stable/#activation-by-environment-variable).
newville commentedon Jan 13, 2017
anntzer commentedon Jan 13, 2017
github-actions commentedon Feb 28, 2023
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!