Posted by
Kenneth Sloan-2 on
Sep 10, 2019; 7:57pm
URL: http://imagej.273.s1.nabble.com/moving-Java-plugins-from-highly-interactive-to-batch-friendly-tp5022429p5022437.html
Thank you for these pointers. I anticipate *major* restructuring for some
plugins. They were all conceived as highly interactive, with several layers
of dialog boxes for options (and repetitions) - but some of them are beginning
to be useful in processing 100's of images. I'm reaching the tipping point,
where it will be time-efficient to restructure rather than push buttons mindlessly.
The good news is that most of these "production run" modules are already separate pieces - they
just aren't plugins in their own right. I need to choose between making them full-blown plugins and simply
writing more high-level Java code to do the repetitions. Right now, I'm strongly neutral on this.
That's because in my personal working style, it is faster for me to write custom Java code than
it is to use a scripting language. "When all you have is a hammer, every problem looks like a nail."
I tend to use ImageJ as an environment to run fairly complex Java programs that happen to deal with images (and
do lots of other things). I also deal with a moderate-sized complex of image-containing objects that communicated with each other - so the idea of a plugin that operates on a single image doesn't quite fit. But...I'm going to try.
I appreciate your guidance.
> I would suggest to structure your plugins as SciJava Commands, with
> the @Parameter annotation. Then you will not need UI code, at least for
> "run-and-done" commands, and they will work headless, and record script
> snippets using the Macro Recorder [1]. Check the imagej/tutorials
> repository for examples [2].
--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html