Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unify radio button group implementations #523

Open
pixelzoom opened this issue Aug 29, 2019 · 4 comments
Open

unify radio button group implementations #523

pixelzoom opened this issue Aug 29, 2019 · 4 comments

Comments

@pixelzoom
Copy link
Contributor

8/29/18 dev meeting:

We currently have 2 very different radio button "groups": RadioButtonGroup and VerticalRadioButtonGroup. They should be unified, so that we're not duplicating code related layout, a11y, sonification, phet-io, etc.

@ariel-phet asked me to describe a "road map" for accomplishing this.

@pixelzoom pixelzoom self-assigned this Aug 29, 2019
@pixelzoom
Copy link
Contributor Author

The first thing that I should do is review issues related to RadioButtonGroup and VerticalRadioButtonGroup.

@pixelzoom
Copy link
Contributor Author

pixelzoom commented Oct 24, 2019

Open sun issues related to radio buttons:

#259 Do we need other types of Radio Buttons?
#260 Do we need 3D vs flat look for radio buttons?
#261 Why don't radio buttons use the sun "button" framework?
#263 Why are some radio buttons is sun/js/buttons/ while others are in sun/js/?
#264 RadioButton not used by RadioButtonGroup. Should it be? Do we still need it?
#361 RadioButtonGroup description
#364 RadioButtonGroup.md General Design Considerations, etc
#399 should Checkbox and AquaRadioButton pointer areas fill width of containing panel?
#505 Radio buttons should have a default sound
#513 should RadioButtonGroup support grid layout?
#550 AquaRadioButton and RadioButtonGroup are instrumented differently

@pixelzoom
Copy link
Contributor Author

pixelzoom commented Oct 24, 2019

Roadmap:

  1. Triage the above issues to gather requirements.

  2. Review/revise this roadmap based on requirements, present to dev team for consensus.

  3. Factor out base type RadioButton and create 2 subclasses: AquaRadioButton, RectangularRadioButton. (RectangularRadioButton might just be a RectangularToggleButton.)

  4. Factor out subclass Group (better name?) that handles "groupness" (layout, visibility,...) and is independent of component and layout type. Handle existing layout types (VBox, HBox, GridBox) and future layout types.

  5. Make RadioButtonGroup a subclass of Group. Make RadioButtonGroup able to handle any type of RadioButton. Create subclasses AquaRadioButtonGroup and RectangularRadioButtonGroup that handle anything specific to radio button subclasses.

  6. Consider the need for other Group subclasses, e.g. CheckboxGroup.

  7. Uniform PhET-iO instrumentation for all radio button types and groups.

  8. Uniform a11y instrumentation for all radio button types and groups.

Back to @ariel-phet for assignment and prioritization.

@ariel-phet
Copy link

@chrisklus is up for this, will be a bit of a "chip away" project in all likelihood. Currently marking as low-priority, to be discussed once his work on Number Play has mainly wrapped up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants