flake8 needs to pass 😉https://travis-ci.org/matplotlib/matplotlib/jobs/489577517

For the failing flake8 test, I would suggest adding the check directly to your text editor.

Milestoning 3.2 as there has not been activity recently.@mromanie are you still interested to work on this?

@timhoffm Apologies for my inactivity. I am indeed still very much interested in working on this. In fact, I think I managed to do it properly by using patches.Ellipse instead of patches.Circle and stretching them to look circular using the aspects of the axes and figure. In this way, the entire surface of the buttons is sensitive, unlike the current implementation with patches.Circle.

I still need to clean up the auto-scaling of the size of the symbols, which at the moment still results in the symbols to overlap under certain circumstances, and I'll submit the whole lot for review. Shall I use the same PR for this?

What about using aPathCollection with a circle marker, such that cicles always stay circles independent on the figure- or axes- dimension or aspect?

@ImportanceOfBeingErnest I'm not familiar withPathCollection, so I don't know what are the advantages/disadvantages. The gist of what I have implemented is as follows, which seems to do a reasonable job:

fig = ax.get_figure()
fh, fw = fig.get_figheight(), fig.get_figwidth()
rpos = ax.get_position().get_points()
rscale = (rpos[:,0].ptp() / rpos[:,1].ptp()) * (fw / fh)
circle_radius = 0.25
p = Ellipse(xy=(0.15, y), width=circle_radius, height=circle_radius*rscale, edgecolor='black', facecolor=facecolor, transform=ax.transAxes)

Plus a couple more things to make it backwards compatible. Like I said earlier, setting circle_radius to a fixed value is not always satisfactory and I' fine-tuning it.

...forgot to say, the condition to activate the Ellipse button is:

((xy[0] - p.get_center()[0])/p.width)**2 + ((xy[1] - p.get_center()[1])/p.height)**2 <= 1

If you plot ascatter plot with circular markers (marker="o") you may have noticed that those markers will stay circles even if you resize the figure, change the aspect or zoom into the plot. This is achieved inside thePathCollection by defining the circle path in display coordinates and using an offset transform to shift those circles at the respective positions in data coordinates. I would think the same can be done here. The advantage compared to the strategy above would be that the bullets will keep their size when resizing the figure after it has first appeared on screen.
In addition, checking the clicks on the bullets could be simplified by using apick_event.

OK, thanks!

All things considered, I would stick to the solution with Ellipse because:

• Zooming is disabled for the axes containing the RadioButtons.
• It is true that the Ellipse looses its circular shape when the entire window is resized, but I'm not sure that this is a problem.
• The solution entails minimal changes wrt the current implementation.
• It is straightforward to make it backwards-compatible by mimicking the current behaviour.

Not sure what the status is here. Since someone asked a question about horizontal buttons on stackoverflow, I thought it might be worth showing a solution over there:https://stackoverflow.com/questions/55095111/displaying-radio-buttons-horizontally-in-matplotlib/55102639#55102639

Of course this could also be used for this update.

This looks mostly done, but needs a rebase and a small tweak to the checks. The squashing is something that affects vertical buttons too, so could be a separate PR.

Are you guys still working on this? Its been 5 years for what seems like a trivial (but very useful) feature

I'm using this patch locally and it has been working fine for me for a while now.

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.

It looks like there isn't much left to do here,@mromanie do you have the bandwidth to do so or are you okay w/ someone else closing this out?

It looks like there isn't much left to do here

Um, I disagree#13374 (comment)

It looks like there isn't much left to do here

Um, I disagree#13374 (comment)

To me put labels next to rather than on top reads like a relatively small/clear change if there's agreement that that should be the position.

What am I missing here?

o me put labels next to rather than on top reads like a relatively small/clear change if there's agreement that that should be the position.

What am I missing here?

That depends on your size of small 😆. Putting the buttons above the text a bit simpler because you only calculate the centers and center-align text and button to these coordianates. For horizontal, you have to think a bit more: What is the starting point for each buttom+text group, how much offset does the text need from the button? It's not terribly complicated, but needs a bit more effort.

For my purposes, I would prefer the labels to the right of the circles. Horizontal radio buttons are supposed to be used when vertical space is limited. Placing labels above the circles reduces the efficiency of the solution.
It can also be used instead of dropdown menus, which also do not exist.
Is there any chance that this will be implemented soon?

Is there any chance that this will be implemented soon?

This is not a priority of the core developers. So unless somebody steps up to contribute, it won’t be implemented soon.

So unless somebody steps up to contribute, it won’t be implemented soon.

Just to add to this, one way to contribute is to take over this orphaned PR and get it to the finish line by addressing/implementing the feedback in#13374 (comment)