Improved file inputs for scripts

[imagejan]

This PR supersedes #276 and #285. (I created a new one because I made further changes to the chooseFiles method signature that can be discussed here.)

Together with the changes in scijava/scijava-ui-swing@master...imagejan:file-input-enhanced and imagej/imagej-legacy@master...imagejan:file-input-enhanced, this renders File[] inputs possible to be resolved interactively:

• Single inputs of type File[] will open a file chooser that allows multiple files/directories to be opened.

• When combined with other script parameters, a list widget is created, e.g. the following Groovy script will show the input dialog shown below:

  #@ File[] (label = "Input files", style = "files,extensions:tif/png/jpg") fileList
  #@ String (label = "Other parameter") stringInput
  
  fileList.each {
  	println "$it is being processed."
  }

  

• A simple filter for file extensions can be created via style attributes as shown in the example (keyword extensions followed by : and the desired extensions separated by /).

• Both File and File[] input widgets are now drag-and-drop targets.

• Double-clicking an item on the file list removes it from the list.

@ctrueden if you happen to have a look, feel free to force push changes to the file-input-enhanced branch on my fork (I checked Allow edits from maintainers, so you should be able to push to my fork?!). I'll be mostly offline next week, but would love to hear/read your opinion when I'm back in the office on August 7.

[ctrueden]

Thanks @imagejan. Two issues I see:

1. We need to avoid the Guava dependency here for splitting the string.
2. The "Refactor multiple file input" commit should explicitly mention that it is OK to break the chooseFiles API here because that API is new and has not yet been released.

Working on it now!

[imagejan]

@ctrueden wrote:

We need to avoid the Guava dependency here for splitting the string.

I was speculating on what you said here:

And it is likely we'll have a dependency on com.google.guava:guava in the future too.

... as I found this super useful 🙂

[ctrueden]

it is likely we'll have a dependency on com.google.guava:guava in the future

Yeah, I am torn. I meant it more generally: the ImageJ software stack will almost certainly depend on guava for, e.g., scijava-types, which will be a dependency of scijava-ops. But I am still reticent to make scijava-common itself depend on guava. We have minimal dependencies now, and even less or none in the future (we could bake in eventbus for example, and push the parsington dependency downstream somewhere). If SJC itself depends on guava, this will be a dealbreaker for some use cases.

[ctrueden]

After a pair programming session with @imagejan, this is ready! Hooray! 👍