Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Horizontal radio buttons#13374

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
mromanie wants to merge1 commit intomatplotlib:main
base:main
Choose a base branch
Loading
frommromanie:horizontalRadioButtons

Conversation

mromanie
Copy link
Contributor

PR Summary

Add the option to have horizontal RadioButtons. A new optional keyword argument 'direction' is introduced to control it. The new parameter defaults to 'vertical' for backwards compatibility.

PR Checklist

  • Has Pytest style unit tests
  • Code isFlake 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

doronbehar reacted with thumbs up emoji
@jklymak
Copy link
Member

jklymak commentedFeb 6, 2019
edited
Loading

Copy link
Member

@NelleVNelleV left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Thanks for the PR@mromanie !
Here are a couple of comments. I'll do a more thorough review once these are addressed.

Can you in addition add a what's new entry? See doc/users/next_whats_new/README.rst

"""
if orientation not in ['vertical', 'horizontal']:
raise ValueError("Invalid RadioButton orientation: %s" % orientation)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Can you add what are the possible values here?
Can you also add a mock test to make sure it runs, as well as a test to make sure this exception is raised properly.

I also think we need to update the examples to show case this (examples/widgets/radio_buttons.py)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

We have a shortcut function to check options like this and raise an appropriate error now,cbook._check_in_list

@@ -1007,7 +1007,12 @@ def __init__(self, ax, labels, active=0, activecolor='blue'):
The index of the initially selected button.
activecolor : color
The color of the selected button.
orientation : str
The orientation of the buttons: 'vertical' (default), or 'horizontal'.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

The keyword being a bit confusing here, I think it's worth detailing a bit more what orientation means (which is the set of radio buttons are on the same horizontal axis or vertical axis).

@NelleV
Copy link
Member

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

@timhoffmtimhoffm added this to thev3.2.0 milestoneFeb 16, 2019
@timhoffm
Copy link
Member

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

@mromanie
Copy link
ContributorAuthor

@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?

@ImportanceOfBeingErnest
Copy link
Member

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

@mromanie
Copy link
ContributorAuthor

mromanie commentedFeb 17, 2019
edited
Loading

@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.

@mromanie
Copy link
ContributorAuthor

...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

@ImportanceOfBeingErnest
Copy link
Member

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.

timhoffm reacted with thumbs up emoji

@mromanie
Copy link
ContributorAuthor

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.

@ImportanceOfBeingErnest
Copy link
Member

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.

@tacaswelltacaswell modified the milestones:v3.2.0,v3.3.0Sep 5, 2019
@QuLogicQuLogic modified the milestones:v3.3.0,v3.4.0Apr 30, 2020
@QuLogic
Copy link
Member

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.

@QuLogicQuLogic modified the milestones:v3.4.0,v3.5.0Jan 27, 2021
@jklymakjklymak marked this pull request as draftMay 8, 2021 17:07
@QuLogicQuLogic modified the milestones:v3.5.0,v3.6.0Aug 18, 2021
@timhoffmtimhoffm modified the milestones:v3.6.0,unassignedApr 30, 2022
@story645story645 removed this from theunassigned milestoneOct 6, 2022
@QuLogic
Copy link
Member

Selecting by closest button is now merged as#13268. Using a scatter plot to ensure circular buttons is merged as#24474.

I pushed a rebase, dropping the old changes, fixed the review comments and adding a test/what's new entry. I also modified the implementation a bit so that it modifies theplacement of the buttons instead of reversing thelabels (as the latter has ramifications for the active index.)

I'm also working on implementing the same change forCheckButtons.

@QuLogicQuLogicforce-pushed thehorizontalRadioButtons branch from8ea3641 to035517eCompareMarch 19, 2024 02:57
@QuLogic
Copy link
Member

@QuLogicQuLogic marked this pull request as ready for reviewMarch 19, 2024 03:22
@QuLogicQuLogicforce-pushed thehorizontalRadioButtons branch from035517e tof76df0aCompareMay 17, 2024 20:25
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The `.RadioButtons` widget's primary layout direction may now be specified with
the *orientation* keyword argument:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Isorientation the right name? I know we use it in some places, but more in the sense of rotation than arrangement.

Possible alternatives: arrangement, direction, layout, ...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

We use orientation for direction of grouped things in boxplot (and internally in bars)
https://matplotlib.org/devdocs/users/next_whats_new/boxplot_orientation.html

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Boxplot is a counter example. There (as well as bar) it's associated with the rotation of the box = direction of the whiskers. "Vertical" means the distribution is along the y axis and multiple boxes are arranged side-by-side horizontally.

In contrast, here "vertical" would mean multiple radio buttons are arranged stacked vertically.

jklymak reacted with thumbs up emoji
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yeah, I'd say "pack_direction" or "layout_direction". This isn't going to be a heavily used kwarg, so we can be verbose.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

"layout_direction" sounds good.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

With respect to#27946 (comment), is that something we want to useorientation for (giving that this change would be moving towardlayout_direction)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Do you mean text above or to the side of the button? I would not make this configurable but always put the text to the side. This is marginally more work, but the standard look and feel of radio buttons. If we want to add the horizontal layout, IMHO we have to do it properly.

A new optional keyword argument 'layout_direction' is introduced tocontrol it. The new parameter defaults to 'vertical' for backwardscompatibility.
@QuLogicQuLogicforce-pushed thehorizontalRadioButtons branch fromf76df0a tob82537aCompareAugust 21, 2024 22:08
@QuLogicQuLogic modified the milestones:v3.10.0,v3.11.0Oct 9, 2024
@rbroders
Copy link

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

@doronbehar
Copy link
Contributor

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

@mromanie
Copy link
ContributorAuthor

mromanie commentedMar 12, 2025 via email

Yeah, sorry: I originated this and then overlooked to complete it. Anything I should do now? Thanks!Ciao,Martino--Due to my own family/work balance, you may receive emails from me outside of normal working hours. I do not expect a response from you outside of your own working pattern, nor do I expect an immediate response when you are working.From: Doron Behar ***@***.***>Reply to: matplotlib/matplotlib ***@***.***>Date: Wednesday, 12. March 2025 at 08:56To: matplotlib/matplotlib ***@***.***>Cc: Martino Romaniello ***@***.***>, Mention ***@***.***>Subject: Re: [matplotlib/matplotlib] Horizontal radio buttons (#13374)This email was sent from outside of ESO from the address ***@***.***. If it looks suspicious, please report it to ***@***.***I'm using this patch locally and it has been working fine for me for a while now.—Reply to this email directly, view it on GitHub<#13374 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AE5K2YYOOHOR4BRYUT6QMVD2T7R7RAVCNFSM6AAAAABY2HAI2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJWHE3DCNBXGI>.You are receiving this because you were mentioned.Message ID: ***@***.***>[Image removed by sender. doronbehar]doronbehar left a comment (matplotlib/matplotlib#13374)<#13374 (comment)>I'm using this patch locally and it has been working fine for me for a while now.—Reply to this email directly, view it on GitHub<#13374 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AE5K2YYOOHOR4BRYUT6QMVD2T7R7RAVCNFSM6AAAAABY2HAI2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJWHE3DCNBXGI>.You are receiving this because you were mentioned.Message ID: ***@***.***>

@@ -1593,9 +1594,16 @@ def __init__(self, ax, labels, active=0, activecolor=None, *,
button.

.. versionadded:: 3.7
layout_direction : {'vertical', 'horizontal'}
The orientation of the buttons: 'vertical' places buttons from top
to bottom, 'horizontal' places buttons from left to right.
Copy link
Member

@timhoffmtimhoffmMar 12, 2025
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Suggested change
tobottom,'horizontal'placesbuttonsfromlefttoright.
tobottom,'horizontal'placesbuttonsfromlefttoright,distributing
thebuttonsacrossthewholeAxes.TheAxesisdividedintoequal-sized
boxes,andeachbuttonisleft-alignedinthebox.Thereiscurrentlyno
sizecheckwiththeassociatedlabels,sothatlonglabelsmayoverlap
withthenextbox.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Sorry, I did not check what this actually does:

grafik

I strongly think we should follow standard conventions that labels are right of the button not above, because I consider the unusual layout a UX issue. See also#27946 (comment).

grafik

The orientation of the buttons: 'vertical' places buttons from top
to bottom, 'horizontal' places buttons from left to right.

.. versionadded:: 3.10
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Suggested change
..versionadded::3.10
..versionadded::3.11

@github-actionsGitHub Actions
Copy link

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.

@github-actionsgithub-actionsbot added the status: inactiveMarked by the “Stale” Github Action labelJun 6, 2025
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@NelleVNelleVNelleV left review comments

@QuLogicQuLogicQuLogic left review comments

@story645story645story645 left review comments

@jklymakjklymakjklymak left review comments

@timhoffmtimhoffmtimhoffm left review comments

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
New featurestatus: inactiveMarked by the “Stale” Github Actiontopic: widgets/UI
Projects
None yet
Milestone
v3.11.0
Development

Successfully merging this pull request may close these issues.

12 participants
@mromanie@jklymak@NelleV@timhoffm@ImportanceOfBeingErnest@QuLogic@rbroders@doronbehar@story645@tacaswell@anntzer@dstansby

[8]ページ先頭

©2009-2025 Movatter.jp