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.rushfo...@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 > > > > -andy > > > > > > > > > > *From: *openjfx-dev <openjfx-dev-r...@openjdk.org> > <openjfx-dev-r...@openjdk.org> on behalf of Kevin Rushforth > <kevin.rushfo...@oracle.com> <kevin.rushfo...@oracle.com> > *Date: *Friday, 2023/01/20 at 12:27 > *To: *openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> > <openjfx-dev@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://stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem > > > > 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 > > > > >
