Allow to supply SearchAction with custom ActionListener

[imagejan]

Currently, we generate a default ActionListener for every SearchAction in the details pane:

scijava-search/src/main/java/org/scijava/ui/swing/search/SwingSearchBar.java

Lines 514 to 521 in 14315f8

	for (final SearchAction action : actions) {
	final JButton button = new JButton(action.toString());
	button.addActionListener(ae -> {
	action.run();
	if (action.closesSearch()) {
	reset();
	}
	});

Allowing for SearchActions to provide their own ActionListener would allow more flexibility, e.g. displaying a small popup menu (JPopupMenu) with additional (sub-)choices that wouldn't justify the creation of an own SearchAction for them.

This goes in the same direction as #4 to provide more flexibility to define search actions.

The problem with allowing with allowing ActionListener as a parameter would be that we introduce an awt dependency in a UI-agnostic SearchAction, so this would have to be abstracted somehow...

[ctrueden]

We don't have to use ActionListener... we could have our own UI-agnostic interface, no? But perhaps run() is already good enough. Why not simply have the JPopupMenu appear in the action's run() method directly? Do we need a second method in the action?

Alternately, if you want to have a UI-agnostic "sub-actions" mechanism, we could add that.

[imagejan]

My idea was to display a popup menu with options at the position of the button when it is clicked, so I'd actually need to have access to the button, e.g. by actionEvent.getSource().

I realize that this might be too UI-centric after all.