[ImageJ-devel] Headlessness

[Johannes Schindelin]

Hi,

On Tue, 31 Aug 2010, Curtis Rueden wrote:

> I think the "abstract plugin" mechanism that Dscho & you developed is a 
> good start, at least for plugins. Then you do not need a global context 
> flag, but rather GenericDialog is only created in the GUI case. So 
> plugins written using that new style are one big step closer to working 
> headless. I think it is less important that older plugins work headless 
> as-is—they can be converted to use the new style, to solve the problem 
> that way.
> 
> For Menus and Tools, I have not examined them in detail yet, so cannot 
> really comment. Do you have a list of the main offenders? Point to some 
> line numbers in code where it's a problem? It would help save me time.

As I mentioned back in Heidelberg: the main problem is when plugins think 
they should open a GUI. Or show anything.

Split Channels. Plot Profile. Even all the filters that open a new 
(filtered) image. All of that is a problem. (Obviously!)

Why? Because ImageJ plugins do not have a concept of "output". They just 
show stuff, instead of returning _anything_.

> Another thing we could do is write a program that is supposed to run 
> headless, run it so, and see where the exceptions are raised. Then solve 
> them one by one until it works.

That won't work. It is a losing battle to try until you found all of the 
cases where macros go wrong.

The design I put into the abstract plugin was carefully thought through. 
Really.

Instead of letting the developer make a dialog, she has to specify in a 
high-level manner (similar to HTML or LaTeX) _what_ she means instead of 
_how_ it should be displayed. That means both input and output.

It would be positively good if there were things in ImageJ2 that 
discouraged the developer rather strongly (such by breaking his code) to 
open any GUI elements.

Of course, there are -- some -- things that developers would like to do 
with a GUI, such as interactions with sliders, aspect ratio constraining, 
validation routines, etc. _All_ of these should be offered using the 
abstract plugin API. So that nobody has an excuse to make proper plugins 
that run in a headless manner, that indeed could be shipped in a task 
packet to a TV, a mobile phone or a toaster via TCP/IP, returning as 
result packets.

The abstract plugin API should make specifying such things so easy that it 
would be a bigger hassle to implement the GUI stuff yourself (thereby 
breaking macro recording, headless operation, cluster queue submission, 
etc).

Ciao,
Dscho