When to use this functionality and when to use the other? I personally thing that to switch between two different modes one should use a toggle button but i need to convince some people at work. any formal UI literature on the subject? thanks
I don't have references for you, but as a user I can tell you what I would expect.
I would expect the button to change images when you substitute one action for another because you entered a different mode. This is really relevant to save real estate in your toolbars, etc. For example you could have a dedicated play button and stop button with one always being disabled. Using one button saves space since at no point will both be enabled.
I would expect a normal depressed/unpressed toggle button when there is one mode that you either enable or disable. An example of this is "Toggle Mark Occurrences" in Eclipse. Unpressing that toggle button does not constitute a new action, but rather disabling an active mode.
I’m inclined to go with toggling buttons (buttons that “stick” depressed when “on”) rather than swapping images or label for a command button. I can’t cite any formal literature, but my impression is that it makes it easier both to anticipate the action produced by activation and to read the current state. The appearance and behavior of a toggle button is consistent with physical toggle button switches (like the Play buttons on older physical tape recorders). It’s also consistent with option buttons, check boxes, and state menu items, which all indicate their affirmative states through peripheral graphic design rather than labels. When the control looks like a command button (raised appearance), it’s labeled like a command button, the label indicating the action committed like any command button (e.g., “Connect”). When it looks like a state indicator (sunken, like a text box), its labeled suggest its current state (connected).
A single toggle button should only be used when there are simple True and False states to the process (e.g., Connected or not). Otherwise you need two or more “segmented controls” (abutting toggling buttons) to ambiguously indicate the alternatives (e.g., Forward vs. Reverse). This is analogous to using two option buttons in place of a check box.
Swapping labels to indicate changes in a button’s action can work if you use text labels that unambiguously indicate the action committed on activation, e.g., (“Connect” and “Disconnect”). While the Play/Pause button is a defacto standard, I’d otherwise avoid using an icon or image because it may confuse users on whether the label is indicating the current state or the state they’d get on activation (i.e., the opposite). There have been buttons that do one or the other, so the user can’t rely on experience. An image it not clearly a verb or adjective, so labeling with an image is tantamount to using text labels like “Online” and “Offline.” Even if done right, swapping labels has the disadvantage that the user needs to do a weird mental transformation to read the affirmative state (“It says I can disconnect, therefore I must be online now”). It can also mean you need a wordier label.
Related
I am writing a Java program to record some events and their status, i.e., done or not. I have implemented the recording and calculations, but I also want to have a button that will open another window that will list the events with a checkbox corresponding to each of them, so I can pick which ones' statuses I will change to done. I have only used Swing libraries so far.
I want this window to contain one event per line, with a checkbox next to the event. Each checkbox should determine whether the status of the even should be changed or not. I had trouble even making such a window open and list the items, let alone put the checkbox.
Note: The design is not too important. This won't be a published project, I will mostly use it for personal work. I can do with buttons instead of checkboxes, where any click changes the status of the event next to it.
Thank you in advance for your valuable responses.
I have a toggle JButton that, when clicked, either installs or uninstalls some listeners elsewhere (but that's somewhat irrelevant I believe, as it could be just about any code that you don't want executed any number of times in a row, hence, the toggle, you click it once, it does something, you click it again, it undoes that something or whatever). My problem is that I have several instances of this button (or more specifically, several instances of its parent JPanel). This restriction is not my doing and I cannot prevent this. Basically, I'm left with a situation where the user can toggle the button "on" a bunch of times in succession, and needless to say, this screws things up for me.
The buttons themselves are not all visible to the user at once, only one can be seen at any given time. I tried using a component listener, but componentHidden() and componentShown() are never called.
I tried making the button a singleton, but that just had this weird effect of only displaying the button on the last panel it was added to.
I'm kinda stumped. The behaviour I want is simple: Multiple instances of this toggle button that sync their selected state. Ideas?
P.S. I suppose I could construct a list of the instances and update all the other's state when one of them is clicked, but I wonder if there's something simpler out there.
Thanks
Yes, the buttons must all be distinct, but they can either share the same ButtonModel or the same Action. Usually, I try to have them share Actions by creating a single Action that extends AbstractAction, and use it to set the Actions of all the same buttons.
No big reveal here. I solved my problem using my own suggestion, that is, I simply kept a list of all the instances of the button and set their states when any one of them was clicked in an action they all share.
I want to display to user that a check box cannot be selected. I have made it greyed, but I wanted to show a cross (X) in the check box instead of default tick) on selecting.
Is there a way to show cross mark in the check box when it is selected.
SWT Widgets are OS dependent, meaning that the OS determines what they look like.
Consequently, there is no way of making a Button show a "X" without considerable coding on your side.
Your best option would be to create a completely new Widget based on Composite or Canvas and do the painting completely yourself.
Sorry the title is fuzzy, but I really coudln't come up with a fitting title.
I'm developing my first application with Swing, and I'm having a hard time figuring out how to keep track of the current view of the application. With I mean with current view is for example if a button has already been pushed. For example, you shouldn't be able to press "Execute" before a file has even been loaded. I've come up with an architechtural solution to this that is really crappy, and I'd like tips on how to improve it.
I have a label called infoText, and it's updated pretty much every time I press a button. Through this, I'm keeping track of the applications state in this fugly way:
if (infoText == LOADING_NARROW){
printSelected(narrow_list);
}else{
printSelected(list);
}
Rather than keeping track of your state with GUI components, use normal Java objects and variables.
Just keep a boolean loadingNarrow in this case that you reference and update when needed.
Also if you are running a large load as the result of a button press and don't want the user to press it again you can disable the button once the load starts and re-enable it later. (Note I am assuming you are running the load on a separate thread so the GUI does not freeze).
Swing Components keep track of their own states.
My advice:
Initiate the application to a default state.
Adjust the settings in an event driven manner. For instance when JButton A is clicked, enable JButtons B and C and set a JTextField.
Check the states of objects with their builtin methods. Example
if((jButtonA.isEnabled() && jTextField.getText().equals("foobar"))
You can also use the mediator pattern to group related components and their actions.
First: Are they different methods, or a copy-paste-error?
printSelecteds (narrow_list);
printSelected (list);
Second: To disable a button you usually use:
ok.setEnabled (false);
If the file is loaded, you call
ok.setEnabled (true);
to enable the JButton "ok".
I don't see how that is related to your info-text, and to your printSelected(s) method. If you pass the state via the GUI, you might loose the one or the other due to race conditions. Changing a label could be the sink of an state change.
You could have mutual exclusive bit patterns to allow interference:
FILE_OPEN = 1;
SEARCHED = 2;
FRIDAY = 4;
to add them bitwise:
state |= FRIDAY
to ask them up in a binary pattern:
if (state | FILE_OPEN) ....
It doesn't look very elegant to me. I guess I'm not sure what your problem is. :)
To fire an action if some button is pressed, you have to implement an actionListener, which could modify your label as well. But the swing eventloop will already check the state of your components. You seem to duplicate the work partly.
I have a menu with a few JCheckBoxMnuItems. How do I ensure that the Menu stays open until I have done all my selections (i.e. checked the menuitems) and does not close on just clicking one of them?
I'd rather not try to change the normal menu behavior for an application or for a part of the menu tree. A User expects that the menu closes automatically after a menu item is clicked. And, if you kept the menu expanded, what kind of action would you invent to close it manually after you've done your last selection?
If there's a requirement to change more then one setting within one use case, then you should consider to provide a small dialog where the use can apply the changes and confirm them at once. I believe, that's more consistent with typical behaviors of UIs.
And it declutters the menu bar, you'll have just one 'setup' menu item instead of a dozen (?) check box actions :)
I guess menu's aren't supposed to allow multi-selection.
But you may offer keyboard shortcuts to set the menuitems without using the menu at all.
If the set-operation of your flags is a central aspect in your application, I would tend to use a dialog here. These are all suggestions which do not require to change the internal implementation of the existing controls, even though I know, that it would be possible in swing.
I agree that it is better to do this with standard UI. However, if do you want to add checkboxes that do not close the menu it is surprisingly easy:
JCheckBox checkBox = new JCheckBox("Text");
checkBox.setOpaque(false);
checkBox.setRequestFocusEnabled(false);
menu.add(checkBox);
This may not work on every look and feel and the check boxes will not line up with menu items in the same manner as JMenuItems but it seems to be a reasonable place to start.