moving Java plugins from highly interactive to "batch friendly"

[Kenneth Sloan-2]

I have (almost exclusively) implemented Java plugins for ImageJ which
are highly interactive.  While I have tried to compartmentalize the
user interaction (mostly through dialog boxes) from the actual
computations, I haven't always been completely successful.

I'm looking for "best practices" on writing Java plugins which require
multiple parameters - and which are written to accept these parameters either
from their invocation, or as responses from  user interacting with dialog
boxes.

The movivation, of course, is that now many of the things which I have written
as "exploratory, interactive mini-applications" have entered the world of "production use".
I'm "on deadine" now with processing that will take me 8 hours to do interactively.  I suspect
it will take me MORE than 8 hours to modify the existing code to be script-driven, but...once
I get past this deadline I'll be strongly motivated to do some serious re-writing.

One or two really good examples would be wonderful.

--
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

[feelc]

Hi Kenneth,

I guess you're asking a software architecture question-Correct me if i'm
wrong. You can check Mvc,  hexagonal and microservices patterns. Hope
that's in line with what you're looking for.

Best,

Felipe

On Mon, 9 Sep 2019, 21:21 Kenneth Sloan, <[hidden email]> wrote:

> I have (almost exclusively) implemented Java plugins for ImageJ which
> are highly interactive.  While I have tried to compartmentalize the
> user interaction (mostly through dialog boxes) from the actual
> computations, I haven't always been completely successful.
>
> I'm looking for "best practices" on writing Java plugins which require
> multiple parameters - and which are written to accept these parameters
> either
> from their invocation, or as responses from  user interacting with dialog
> boxes.
>
> The movivation, of course, is that now many of the things which I have
> written
> as "exploratory, interactive mini-applications" have entered the world of
> "production use".
> I'm "on deadine" now with processing that will take me 8 hours to do
> interactively.  I suspect
> it will take me MORE than 8 hours to modify the existing code to be
> script-driven, but...once
> I get past this deadline I'll be strongly motivated to do some serious
> re-writing.
>
> One or two really good examples would be wonderful.
>
> --
> 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
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

On Monday, 9 September 2019 19:57:25 BST [hidden email] wrote:
> I'm looking for "best practices" on writing Java plugins which require
> multiple parameters - and which are written to accept these parameters
> either from their invocation, or as responses from  user interacting with
> dialog boxes.

Hi Kenneth,
Long ago, Albert Cardona wrote some plugin design guidelines that I found very
useful for plain IJ plugins (not sure if those still apply for IJ2) showing
how to separate the dialog from the execution. That makes it easy to then call
the exec method of a plugin from another plugin if you know the expected
parameters. It also separates the various preliminary tests (e.g. image type)
from the exec method. Another interesting suggestion is to return but not show
the result image in the exec method.

https://imagej.net/PlugIn_Design_Guidelines

Maybe for most "proper" programmers (which I am not) all this is very obvious
(sorry if it is!), but it was most informative for me .

Regards

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Curtis Rueden-2]

Hi Kenneth,

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].

Adapting more complex interactive commands is more complicated. If you have
a well-designed public API which exposes the processing separate from the
UI, you can call that API from any of ImageJ's supporting scripting
languages [3]. To call your API from ImageJ macro is trickier, but can be
done in a relatively general manner by:

A) Using the 'call' function if you have public static methods that accept
only string arguments; and/or:
B) Using the 'eval("js", script)' function passing JavaScript code.

Regards,
Curtis

[1] https://imagej.net/Recorder
[2]
https://github.com/imagej/tutorials/blob/27d059117b3bfd1c73d8300f3193db11f6aebb9d/maven-projects/simple-commands/src/main/java/GradientImage.java#L21-L45
[3] https://imagej.net/Scripting

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
Have you tried the Image.sc Forum? https://forum.image.sc/

On Mon, Sep 9, 2019 at 1:58 PM Kenneth Sloan <[hidden email]>
wrote:

> I have (almost exclusively) implemented Java plugins for ImageJ which
> are highly interactive.  While I have tried to compartmentalize the
> user interaction (mostly through dialog boxes) from the actual
> computations, I haven't always been completely successful.
>
> I'm looking for "best practices" on writing Java plugins which require
> multiple parameters - and which are written to accept these parameters
> either
> from their invocation, or as responses from  user interacting with dialog
> boxes.
>
> The movivation, of course, is that now many of the things which I have
> written
> as "exploratory, interactive mini-applications" have entered the world of
> "production use".
> I'm "on deadine" now with processing that will take me 8 hours to do
> interactively.  I suspect
> it will take me MORE than 8 hours to modify the existing code to be
> script-driven, but...once
> I get past this deadline I'll be strongly motivated to do some serious
> re-writing.
>
> One or two really good examples would be wonderful.
>
> --
> 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
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

Thank you, Gabriel - I think that is *exactly* what I need.

--
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

[Kenneth Sloan-2]

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