Repository navigation
Allow to supply SearchAction with custom ActionListener #10
Description
Activity
We don't have to use
ActionListener... we could have our own UI-agnostic interface, no? But perhapsrun()is already good enough. Why not simply have theJPopupMenuappear in the action'srun()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.
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.
Currently, we generate a default
ActionListenerfor everySearchActionin the details pane:scijava-search/src/main/java/org/scijava/ui/swing/search/SwingSearchBar.java
Lines 514 to 521 in 14315f8
Allowing for
SearchActions to provide their ownActionListenerwould allow more flexibility, e.g. displaying a small popup menu (JPopupMenu) with additional (sub-)choices that wouldn't justify the creation of an ownSearchActionfor them.This goes in the same direction as #4 to provide more flexibility to define search actions.
The problem with allowing with allowing
ActionListeneras a parameter would be that we introduce an awt dependency in a UI-agnosticSearchAction, so this would have to be abstracted somehow...