I do not think that going with scatter is the correct approach here. Looking at the internals ofRectangle we have a (private) knob to account for the aspect ratio

I suspect that making sure this gets set ondraw is a much simpler way to solve this problem.

@tacaswell Just making sure that I'm understanding correctly, but if we do that then we're kinda working on the current implementation itself, right? In that case, we'll also have to make a call on should the checkbox size increase, while maintaining the square shape or not?

I do not think that going with scatter is the correct approach here.

@tacaswell why? Using markers instead of cobbling the box together from basic artists has some appeal. You don't have to bother with aspect. You get pixel snapping. You have only a single artist to change for updating the check state. And you can switch to more complex markers like a check symbol relatively easy.

Note also that@anntzer did the same thing in#24455 with radio buttons.

From a quick look, _aspect_ratio_correction, introduced in#20839 for the rectangle selector widget, seems actually brittle, as 1) it will basically never work for polar plots (not a concern here, but one for rectangle selectors in screen space), and 2) it makes one of the two axises the "main" one relative to the other (I think for circles the radius will effectively be the radius in relative units along the x axis, not along the y axis), whereas the proper thing to do would be to have a radius in pixels (basically proportional to the font size, to make the radio button close to the size of the label).
If we really want to do this with individual artists we'd need Circle to support having different transforms for center and radius (a bit like how PathCollections have both a transform and an offset_transform, which is what we're effectively relying on here).

Fair enough. I missed that we did this for radio buttons and I am biased towards the minimal changes to solve the problem. The consensus is clearly in favor of this so I take back my comment.

I would rather not change the test image, see how I ensured that it still uses the old radiobuttons. We can always reconsider and change both at the same time once the deprecation elapses, but the better way to test the new version is probably to use check_figures_equal like I did in test_radio_buttons.

Ah gotcha. I'll take a look at your PR and do that. Thanks.

The failing check is unhappy because I changed an image and reverted the test image fortest_check_radio_buttons. Is there a recommended way to resolve that? Also, I'm not sure why the docs are failing, I did not make any changes there.

Docs test is because we fail on warnings and you got this warning:

https://app.circleci.com/pipelines/github/matplotlib/matplotlib/20207/workflows/95614b42-e1b0-4ead-850e-66805085a944/jobs/72159?invite=true#step-113-1153

which is a poor interaction with an old changelog entry which didn't use the full name of a reference.

https://github.com/matplotlib/matplotlib/blame/v3.6.2/doc/api/prev_api_changes/api_changes_2.1.0.rst#L425

This line should probably be updated to simply belines (no reference, but codestyled) as it is in a heading (and the proper reference link is right below it anyway...)

anywho, because you are defining a function called "lines" and that reference was not fully specified, it had worked because there was only one target for "lines" previously, but now there is more than one.

As for the PR cleanliness check, are you familiar withgit rebase -i?

here is an article that goes over the basics, probably better than I could in an off hand github comment (though admittedly I only skimmed this article to make sure it wasn't outright incorrect):

https://thoughtbot.com/blog/git-interactive-rebase-squash-amend-rewriting-history

Feel free to ask any additional clarifying questions, its a relatively complicated (and powerful) edge case ofgit

Essentially rather than committing, changing and then reverting that image in separate commits, squashing out the changes to the image entirely will make it so that there is not an extra version of the image in the canonical git history.

Ah okay. That makes sense. Though, should I do anything in this PR to resolve that? That's not close to anything I'm working on here.

Yes, I'm familiar with rebase, just did not want to go rebase stuff without knowing if that was fine since some people prefer not to do that. I'll rebase the commits to remove the image issue. Thanks!

since its a one line change that while it is unrelated to what you were directly working on, it is elevated to a warning by what you were doing, I'd just go ahead and fix it here to keep CI happy rather than opening a separate PR

@QuLogic let me know when you get a chance to look at this. Thanks!

Running this example:https://github.com/matplotlib/matplotlib/blob/main/examples/widgets/check_buttons.py

TheCheckButtons work and show the initial state correctly, but the x 's do not come back when you go from off -> on.

I'm going to push this to 3.8, but if it is indeed ready by the end of the year I am 👍🏻 on it getting merged and being re-milestoned to 3.7.

That issue was not supposed to be there anymore....taking a look right away. Sorry this is taking too long, I keep missing small things with this one for some reason.

@tacaswell corrected that. Everything seems to be working locally. Can you check once? Thanks!

@chahak13 Could you squash this to a smaller number of commits?

That should do it. I've kept the major, important commits and squashed all changes into them.

@QuLogic done. Should be good.