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.
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'm developing an Eclipse plugin that has a toolbar menu item that will be enabling/disabling a feature. I know how to set the icon and tooltip text for it using the plugin.xml file, but I want to be able to change the icon and especially the tooltip text for it depending on the state of the project being worked on. I.e., if the feature is not enabled, I want an icon that shows turning the feature on along with tooltip text that says "enable feature", but if the feature is enabled, I want an icon that shows turning the feature off along with tooltip text that says "disable feature". Right now, the only option I can see is a generic icon and tooltip text that says "enable/disable feature", but that feels clumsy to me.
Edit to add: In response to indigomonkey's answer, which is a good one based on what I originally wrote, I would like to clarify that the behavior that is being enabled by the toolbar button is one that we really discourage ever disabling once it has been enabled (and a dialog pops up both to when enabling it to verify that they want to enable it because it should not be started lightly as well as to discourage them from disabling it once it is enabled). Because of this, I would like the icon to change to one that suggests "don't click on me".
If your command Handler implements IElementUpdater the updateElement method will be called whenever the command is run.
The UIElement parameter of updateElement has setIcon and setTooltip methods.
I would suggest that you choose to create your toolbar contribution as a 'checkbox' type, rather than the standard 'push'. This will mean that the button will toggle between a selected and unselected state, allowing you to equate this behaviour to the enabled and disabled state of your feature.
If you're using org.eclipse.ui.commands and org.eclipse.ui.handlers along with the org.eclipse.ui.menus extension point to contribute your button with a <command> element, you'll need to set its style attribute to check. You can then read and toggle the command's selection from inside the handler.
For more information, see http://blog.eclipse-tips.com/2009/03/commands-part-6-toggle-radio-menu.html.
In rcp E4 the solution seems to be a bit different. Since I first stumbled accross this question, I want to summerize/link the solution for future developers.
The relevant questions, where I found the answer are Switch Image of a Handler in a e4 rcp and RCP 4 Toggle a button in the toolbar.
Basically you need to add the argument MToolItem to your Execute-method like this:
#Execute
public void execute(final MToolItem item)
{
item.setIconURI("platform:/plugin/......");
//additional changes e.g. to the tooltip are also possible.
}
If you additionally give your toolbarbutton type checked
<elements xsi:type="menu:HandledToolItem" type="Check" ...
the item will automatically toggle between selected/unselected with each click. You can get the current state with
item.isSelected(). As a side effect, the toolbar icon will be highlighed in the selected-state. If you don't want that, you need to keep track of the state yourself.
I want to create a popup menu which has a few "big" (special) items.
These "big" items should somehow behave like submenus, but they are large panels (with buttons, labels, combo boxes, etc.). These panels should all appear when the mouse is over (or pressed at) the corresponding menu items, and they all should appear in the same screen area just next to the popup menu, beneath the topmost item entry, not aligned to their corresponding item). The last-selected of them can remain visible as long as the popup is visible.
Basically, I believe this feels like (A) putting a JLayeredPane next to the popup menu, and switching the layers according to some mouse events. Probably this would require to fake the whole popup menu using a single large JPanel inside a JPopupMenu having just this one entry (i.e. also all "ordinary" menu items would in fact have to be buttons.)
So, on the other hand (B), it seems probably smarter to use standard swing submenu items, add the big panels as submenu items, and then force all the submenu items to the same location and size. Though, I am not sure if this will work and whether there will be such problems like the menu getting instantly hidden as soon as the user clicks a combo box inside one of the big panels.
Would you recommend going for either (A) or (B) — or perhaps (C) ?
Any experiences / known pitfalls doing such things?
Kind regards,
Philipp
I don't have experience with A or B, but between the two I would try B first.
Another option that might be better is to use a JDialog. Set to to be undecorated and hide it when it loses focus. (This might just be an easier way to do A).
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.
Imagine I'm making a simple Word Processor with Java Swing. I've got a set of Actions written to perform text justification. On the MenuBar I've got a menu:
View
Left Justify
Center Jusitfy
Right Justify
This consists of JRadioButtonMenuItems and a ButtonGroup to ensure only one item is selected at any one time.
Also, imagine I've got an equivalent toolbar consisting of JToggleButtons and again a ButtonGroup to ensure only only button can be active at any one time.
The "Left Justify" JRadioButtonMenu and JToggleButton are initialised using the same Action, and so on with the other items.
My question is this: what is the best method for syncronizing the two groups? If I click "Right Justify" icon on the toolbar, I want the group in the Menu to be updated accordingly, and vice versa.
I after a lot of searching I found information here. Basically, you can add this to your action's actionPerformed method:
action.putValue(Action.SELECTED_KEY, Boolean.TRUE);
And this will do all the work for you!
Unfortunately the official Sun tutorials don't cover this aspect (or at least I didn't spot it), hence the difficulty in spotting such a simple approach to resolving my problem.
Observer pattern my friend. The menu bar observe the toolbar, and the toolbar observe the menu bar. They will both be observer and observable. Each one has his own listener which, on a change event, notify the observer (the other one) with the new value in parameter.
One of the great advantage of the observer pattern is that there is very low coupling, so you don't need a lot of refactoring to implement the linking, to modify it or to remove it in the future.
Take a look at the Mediator Design Pattern
If you are using the Swing Actions the components should be disabled/enabled automatically if the action itself is. You can register yourself as a propertyListener to an action as well to monitor other changes. Look at http://java.sun.com/javase/6/docs/api/javax/swing/Action.html for detailed list of which properties are available.
On the other hand (me again), you could just write 1 listener in an external class. A listener for the menu and for the toolbar. When 1 changes, the listener set them both to the new value.