[External] : Re: RFC: new property in ToggleGroup
John Hendrikx
john.hendrikx at gmail.com
Mon Jan 23 21:29:36 UTC 2023
Radio buttons are a very common UI control that are well understood by
users familair with UI's of the past decades, and also for programmers
reading the resulting state of the radio buttons. Allowing deselection
would be something users have not seen before, and I'm sure every UI
styleguide out there will advocate against allowing this even if it were
possible in the UI toolkit of choice. Allowing deselection is also
something programmers have not seen before (did the user really select
nothing, or is it still in its default state?) Therefore, having JavaFX
support such a feature would be supporting something that will probably
be avoided by everyone making UI's that are easy to understand by users.
I think we'd need to see more use cases, and also requests from other
users before considering such a feature. Even then it would go against
years of UI design and user familiarity with UI's on practically every
platform (it's amazing to be honest that almost all platforms use the
same concept for a group of choice of which only one can be selected).
If a radio button group really needs a way to express "none of the
above", then another option can be added that does exactly that.
--John
On 23/01/2023 19:04, Andy Goryachev wrote:
>
> It is indeed the same in Swing: the initial state for a ButtonGroup is
> all deselected. Kevin brought up a good example with HTML radio
> buttons - in effect saying that this initial state indicates that the
> user needs to make a choice, which is the most frequent case in an
> HTML page.
>
> However, it may or may not be the case in FX. Consider, for example,
> a case where a file viewer presents a number of modes - (text | hex |
> image) to present a file. These modes are mutually exclusive (thus
> requiring RadioMenuItems or ToggleButtons), but one *must* be selected
> initially, since it does not make sense to ask the user to make a
> choice, instead a default choice must be made by the application.
>
> Yes, it can be simply solved by making a default one selected in the
> code, and that is what is usually done. I just thought that having a
> property would eliminate extra code. One can also extend ToggleGroup
> to provide that functionality, and that is what I have done in the past.
>
> Thank you all for the discussion and insightful comments. Given the
> negative feedback and availability of easy workaround I withdraw this RFC.
>
> Cheers,
>
> -andy
>
> *From: *Nir Lisker <nlisker at gmail.com>
> *Date: *Saturday, 2023/01/21 at 08:22
> *To: *Kevin Rushforth <kevin.rushforth at oracle.com>
> *Cc: *Andy Goryachev <andy.goryachev at oracle.com>,
> openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *[External] : Re: RFC: new property in ToggleGroup
>
> I don't see it being especially useful. GUI's tend to work this way. I
> remember it was the same in Swing.
>
> On Sat, Jan 21, 2023 at 1:41 AM Kevin Rushforth
> <kevin.rushforth at oracle.com> wrote:
>
> On 1/20/2023 2:57 PM, Andy Goryachev wrote:
>
> I just want to add one thing - the initial state of
> RadioMenuItems added to a menu is unselected, even if they
> belong to a ToggleGroup.
>
> One can say that having all unselected radio buttons in a
> toggle group makes no sense, or perhaps it depends on the
> application requirements - though I cannot find an example
> where it might be needed.
>
>
> Yes, it's initially unselected unless the app makes an explicit
> selection. HTML radio buttons work the same way [1]. Some apps use
> that to indicate that nothing was selected, but then once you
> select it there will always be something selected.
>
>
>
> So either we allow two different policies by adding a property
> to the ToggleGroup, or we proclaim that adding a radio button
> to a toggle group must have a side effect of one (first)
> button to be automatically selected, otherwise the whole group
> is in inconsistent state (or the app developer must write some
> code to select one).
>
>
> I wouldn't want to change the default behavior, since I can
> imagine some apps relying on being able to tell if the user has
> ever selected any of the choices.
>
> Having two properties would be one solution, presuming we think
> that we need to provide a way for the app to indicate that it
> wants us to enforce the invariant of ensuring that the app can't
> ever get the control in a state where nothing is selected.
> Although, since it would be an opt-in, the app could just as
> easily set the default itself as opposed to setting this new property.
>
> -- Kevin
>
> [1]
> https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_radio
> <https://urldefense.com/v3/__https:/www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_radio__;!!ACWV5N9M2RV99hQ!IHUhh-zd22k26dpWxaIMIQPWkUKslHglTRC3u7NgvYYyYi4ZLWiijdogZwo2f9iRPTRGkKW9kGAzk6Vz7Whx$>
>
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
> <mailto:openjfx-dev-retn at openjdk.org> on behalf of Kevin
> Rushforth <kevin.rushforth at oracle.com>
> <mailto:kevin.rushforth at oracle.com>
> *Date: *Friday, 2023/01/20 at 12:27
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> <mailto:openjfx-dev at openjdk.org>
> *Subject: *Re: RFC: new property in ToggleGroup
>
> How common a UI feature is being able to deselect the selected
> item in a ToggleGroup via the UI such that no item is
> selected? I don't normally see that in various apps or
> toolkits that I am familiar with. What I do see is that either
> a default item is selected or no item is selected initially
> (which is the one and only time that there will be no item
> selected), but in both case, once you make a selection, there
> is no way via the UI to deselect the current item. Absent a
> compelling need, I think the current behavior (once the fix
> for JDK-8237505 is integrated) is sufficient.
>
> What do other developers think?
>
> -- Kevin
>
> On 1/20/2023 11:31 AM, Andy Goryachev wrote:
>
> Dear colleagues:
>
> In the context of a recent PR
>
> https://bugs.openjdk.org/browse/JDK-8237505
>
> https://github.com/openjdk/jfx/pull/1002
> <https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1002__;!!ACWV5N9M2RV99hQ!IHUhh-zd22k26dpWxaIMIQPWkUKslHglTRC3u7NgvYYyYi4ZLWiijdogZwo2f9iRPTRGkKW9kGAzkyU-UIVq$>
>
> https://stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem
> <https://urldefense.com/v3/__https:/stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem__;!!ACWV5N9M2RV99hQ!IHUhh-zd22k26dpWxaIMIQPWkUKslHglTRC3u7NgvYYyYi4ZLWiijdogZwo2f9iRPTRGkKW9kGAzk5wy-flH$>
>
> where a number of RadioMenuItems belonging to a toggle
> group are added to the menu, we might want to add a new
> property to the ToggleGroup which controls whether all
> items in a group can be deselected.
>
> If this property is set, a selected radio menu item can be
> deselected via either keyboard accelerator or a mouse
> click. If not, then not only this operation cannot be
> performed, but also the first item added to said
> ToggleGroup gets automatically selected.
>
> This should allow for more flexibility in creating menus
> with RadioMenuItems, but eliminate some boilerplate code
> required in such cases.
>
> The new logic would also affect any Toggle, such as
> ToggleButton.
>
> What do you think? Thank you.
>
> -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230123/8d25e81f/attachment-0001.htm>
More information about the openjfx-dev
mailing list