Bug192 Editing
Radio-box behaviour should be such that once an element is selected (if it initially isn't), one element must always be selected. As it currently stands, a selected radio-box can be deselected, leaving no elements in the set selected.
Just out of curiousity, what's the justification for this behaviour? It's always annoyed me to no end. I can see a requirement that at least one item always be selected, and that'd be useful at lots of times, but if the radio box starts blank why can't you return it to that state? Doesn't that violate the principle of UI design that actions be reversible?
Well perhaps we need two (or more?) different types of radioboxes: - always one selected - at-most one selected However: often I find the cases where one item is *not* selected initially is a programming error; are there cases where this is not true? I far prefer a tick-box to enable the option, then a radio-box to select any type of variable behaviour.
How about just doing like java/swing? That is, the radioboxes don't know anything about any box being selected other than itself. Instead selection policies are implemented through an object (a listener) that monitors all boxes in a "selection group" and can deselect boxes when a box is selected. Thus any arbitrary policy can be implemented without tampering with the boxes themselves.
On Tue, Dec 24, 2002 at 08:25:57PM +0000, anonymous wrote: > > anonymous added the comment: > > How about just doing like java/swing? That is, > the radioboxes don't know anything about any box > being selected other than itself. Instead > selection policies are implemented through an > object (a listener) that monitors all boxes in > a "selection group" and can deselect boxes when > a box is selected. Thus any arbitrary policy can > be implemented without tampering with the boxes > themselves. That's exactly how we do do things, actually. -- Nathaniel
I tried solving this by changing the 'selection' criteria to include Selection::required, as with the toolbar widget. This seems like the 'obvious' way to solve this, thought someone more clear about the system should confirm this :) This does work, as can be easily shown when using the selection (radio-boxes) in the fresco-demo[3D] demos. That would be ok, but if you take a look at the fresco-demo focus demo, you find that while it also works in there, there is a bug. The black frames around each radio-box item ('focus box'?) now stay selected when the focus is on a different group of widgets. I guessed to begin with that this might be due to some relationship between 'active' and 'toggled' states, but that is not true: if you hit TAB to move around within a set of radioboxes, the focus (black-box) moves down but the toggle-status doesn't change. Any clues? Is this something to do with the control graph setup? Third question: can we change 'toggle choice' to 'radiobox choice'...unless the former really is a common term that I'm not aware of!
FyD1xu <a href="http://upmsvyhngsra.com/">upmsvyhngsra</a>, [url=http://vnagspnmgukd.com/]vnagspnmgukd[/url], [link=http://ccehqvezzqoa.com/]ccehqvezzqoa[/link], http://kdhrbzbpndqb.com/
OmP4a1 <a href="http://bnargazywerk.com/">bnargazywerk</a>, [url=http://adbcdinlupxw.com/]adbcdinlupxw[/url], [link=http://kjwxmnqekunm.com/]kjwxmnqekunm[/link], http://aosppvhjptit.com/
not logged in
register
Home