Dscho, I like the cut of your jib, but I'm wondering how backwards compatibility with old plugins fits into your proposal. Can they still make GUI calls as before? Do we try to write some crazy wrapper that shoehorns them into the API?<div>
<br></div><div>Thanks :)</div><div>-Adam<br><br><div class="gmail_quote">On Tue, Aug 31, 2010 at 5:12 PM, Johannes Schindelin <span dir="ltr"><<a href="mailto:Johannes.Schindelin@gmx.de">Johannes.Schindelin@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<div class="im"><br>
On Tue, 31 Aug 2010, Curtis Rueden wrote:<br>
<br>
> I think the "abstract plugin" mechanism that Dscho & you developed is a<br>
> good start, at least for plugins. Then you do not need a global context<br>
> flag, but rather GenericDialog is only created in the GUI case. So<br>
> plugins written using that new style are one big step closer to working<br>
> headless. I think it is less important that older plugins work headless<br>
> as-is—they can be converted to use the new style, to solve the problem<br>
> that way.<br>
><br>
> For Menus and Tools, I have not examined them in detail yet, so cannot<br>
> really comment. Do you have a list of the main offenders? Point to some<br>
> line numbers in code where it's a problem? It would help save me time.<br>
<br>
</div>As I mentioned back in Heidelberg: the main problem is when plugins think<br>
they should open a GUI. Or show anything.<br>
<br>
Split Channels. Plot Profile. Even all the filters that open a new<br>
(filtered) image. All of that is a problem. (Obviously!)<br>
<br>
Why? Because ImageJ plugins do not have a concept of "output". They just<br>
show stuff, instead of returning _anything_.<br>
<div class="im"><br>
> Another thing we could do is write a program that is supposed to run<br>
> headless, run it so, and see where the exceptions are raised. Then solve<br>
> them one by one until it works.<br>
<br>
</div>That won't work. It is a losing battle to try until you found all of the<br>
cases where macros go wrong.<br>
<br>
The design I put into the abstract plugin was carefully thought through.<br>
Really.<br>
<br>
Instead of letting the developer make a dialog, she has to specify in a<br>
high-level manner (similar to HTML or LaTeX) _what_ she means instead of<br>
_how_ it should be displayed. That means both input and output.<br>
<br>
It would be positively good if there were things in ImageJ2 that<br>
discouraged the developer rather strongly (such by breaking his code) to<br>
open any GUI elements.<br>
<br>
Of course, there are -- some -- things that developers would like to do<br>
with a GUI, such as interactions with sliders, aspect ratio constraining,<br>
validation routines, etc. _All_ of these should be offered using the<br>
abstract plugin API. So that nobody has an excuse to make proper plugins<br>
that run in a headless manner, that indeed could be shipped in a task<br>
packet to a TV, a mobile phone or a toaster via TCP/IP, returning as<br>
result packets.<br>
<br>
The abstract plugin API should make specifying such things so easy that it<br>
would be a bigger hassle to implement the GUI stuff yourself (thereby<br>
breaking macro recording, headless operation, cluster queue submission,<br>
etc).<br>
<br>
Ciao,<br>
Dscho<br>
<br>_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagejdev.org">ImageJ-devel@imagejdev.org</a><br>
<a href="http://imagejdev.org/mailman/listinfo/imagej-devel" target="_blank">http://imagejdev.org/mailman/listinfo/imagej-devel</a><br>
<br></blockquote></div><br></div>