use checkboxes and radio buttons correctly
in some places in the UI, radio buttons are used where checkboxes should be
used, e.g., in the "set plot format" dialog this occurs
#2 Updated by Christopher Brooks over 15 years ago
I think I fixed this by modifying ptolemy/gui/Query.java so
that it uses JCheckBox where it should.
I verified that the Plot formatter has square check boxes on the right
and round radio buttons for the Mark.
I also verified that the CT Director configuration panel now has a
square checkbox for "Synchronize to realtime".
In the port dialog, I think we were always using square boxes
for input, output and multiport. A port can be both an input and
an output or neither, so we are ok here.
This change means that all the dialogs in the Ptolemy docs need to be
updated. I'm not sure I like having both square and round boxes, they
make the interface more cluttered. However, it is more correct from
a UI design point of view to use square boxes for check boxes and round
circles for radio buttons.
I'm marking this bug as "Fixed", I hope that is ok with the Kepler folks.
There is a chance that we might revert to the previous behavior, in
which case I'll mark this bug as unfixed.
#3 Updated by Laura Downey over 15 years ago
I just downloaded the latest build of Kepler and it is still showing a radio
button for "Synchronize to realtime". And radio buttons are still showing for
the non-mutually exclusive items on the right of the plot coniguration dialog
also. So I'm not sure what you mean when you say you verified that checkboxes
were being used in some places where previously there were radio buttons.
In addition, besides using the appropriate widget, labels for checkboxes and
radio buttons should be placed to the right of the radio button or checkbox
(as was done in the "Marks" section in the Plot Format dialog. The only
exception to that is when a checkbox is used within a table like we are doing
in the ports dialog, in that case the checkboxes are correct and the labels
are the column headings.
Radio buttons are designed to be used in mutually exclusive situations where
one choice is allowed from a group of choices. Checkboxes are used when there
is one choice (toggle) or when multiple choices are allowed from a group of
choices. Users recognize them and expect them to be used in the standard
manner with the standard behavior.
There are several other places within the UI where checkboxes and radiobuttons
are used incorrectly. Matt has mentioned a few. As I discover more I will
add them to the list.
Other dialogs include:
Configure/Rename dialog (single radio button should be a checkbox)
Edit Preferences dialog (single radio button should be a checkbox)
Run Window (single radio buttons should be checkboxes)
Configure breakpoints dialog (single radio buttons should be checkboxes)
#4 Updated by Christopher Brooks over 15 years ago
My changes are in the Ptolemy CVS tree. I'm not totally sure
how these changes get propagated to the Kepler build.
I've reopened the bug until we get to the bottom of this.
Keeping a list of places where the bug occurs is helpful, I just
verified that these places are fixed in the Ptolemy tree.
#6 Updated by Christopher Brooks over 14 years ago
I think this problem is fixed and the bug can be closed.
Maybe the bug should be assigned to Laura so she can verify that
the checkboxes are fixed.
If they are not fixed, then the bug could be assigned to me and I'll fix them.
I'm not sure what the protocol is here, so I'm not reassigning the bug.
#8 Updated by Laura Downey over 14 years ago
As I redesign various dialogs, I'm using checkboxes and radio buttons in the
standard fashion. However, there are places in the current UI we haven't
addressed yet which I believe use these incorrectly. This also ties to the
terminology bug too -- there are several places throughout the UI that uses
programmer centric language that needs to be adjusted. So both of these bugs
are broad and I expect them to stay open for quite sometime as we gradually
address them. I'm fine with being assigned as the owner and being responsible
for verification of these kinds of items.