[ImageJ-devel] ImageJ - KNIME Integration: open questions

[Michael Zinsmaier]

Hi Curtis,

thanks for the reply, I just worked through the "code question" 
(version, context, ...) everything  seems to work again.
Now for the other issues

@preview checkboxes
> Michael wrote:
> > Would it be possible to add a flag that surpresses previews checkboxes
> > during dialog building?
>
> It's tricky because right now, each preview checkbox is an input 
> parameter to the command itself. But personally I don't like that 
> approach. It is not a "real" input to the command, but rather intended 
> to be toggled during input harvesting only. One option might be to 
> label the visibility of those parameters as ItemVisibility.INVISIBLE. 
> Then we could add a flag somewhere to hide INVISIBLE parameters, maybe.
>
> But really, I am leaning toward a simpler solution: just remove the 
> preview checkboxes, in favor of ImageJ2 *always* doing a preview (and 
> of course, KNIP doesn't have to). And if the previews are too slow, we 
> can optimize the preview() method to address it, rather than having 
> this hacky checkbox like ImageJ1 does.
I think the 2nd approach could be a good solution. Without a (hacky) 
checkbox we would end up with simply not calling preview() on
Previewable commands. Additionally we could also change this if we 
wanted to support previews in the future.

@interactive commands
> Lee wrote:
> > I hadn't looked at the interactive commands with regard to
> > CellProfiler. It looks like "buttons" could be interpreted as possible
> > headless actions that could be performed... at least in some cases.
>
> Yes, each button generally performs some action, which we should 
> really make sure are always exposed as standalone commands (see next 
> paragraph). We are going to add logic to make multiple sequential 
> Button widgets render as a single button bar in our UI layout. Won't 
> affect you though, Lee, since you do your own UI in Python.
>
> Michael wrote:
> > Why is the threshold  plugin an interactive command?
>
> Let me explain the motivation here. Anything that extends 
> InteractiveCommand is not *intended* to be run in headless mode. 
> Rather, it is intended as a sort of "meta-command" that allows you to 
> launch other commands. It will be filled with callback methods when 
> various inputs change, which should, in a properly designed 
> InteractiveCommand, trigger real command executions that are more 
> well-behaved from a headless standpoint.
>
> Anything that extends InteractiveCommand should *not* be flagged with 
> "headless = true" since it is not intended for that purpose.
>
> So in the case of threshold, we need a "real" threshold command that 
> has sensible inputs and outputs. Then the command exposed in the 
> ImageJ UI as "threshold" is actually "Interactive Threshold" which 
> fires off Threshold executions.
>
> This is not all fully in place, but it is the direction we are going. 
> Sound reasonable?
>
> Lee wrote:
> > For Threshold, I can see reasons for executing the callbacks for
> > "auto", "apply" and "delete" in a headless context
>
> The above would also address your comments here, Lee. The interactive 
> threshold command would not need to be exposed within CP because those 
> buttons would each have a corresponding standalone headless-friendly 
> command which *would* be exposed.
In our case the standalone headless commands would end up as KNIME nodes 
and the interactive meta command would be ignored.
Which should work fine.

I have only one small concern, the headless commands should not become 
to fine granular. Consider for example a filter command that supports 
different neighborhood shapes. A meta command for different filters and 
a headless command for each filter (gaussian, max, ...) is a good solution.
But an implementation with a headless command for each filter and each 
neighbourhood  (gaussian rectangular, gaussian circular, ...) would be 
too much. However thats in the end up to the command implementor and 
shouldn't be a general problem.


@dynamic command detection => ticket filed
> Michael wrote:
> > is there a way to determine if a command is dynamic?
>
> Other than the hacky instanceof test you are doing, nope. I agree we 
> should add API for it to ModuleInfo. Especially because it is possible 
> for modules to be dynamic without extending the DynamicCommand class...
>
> Could you please file a ticket for it on the ImageJ Trac? I just made 
> ImageJ Trac accounts for you, Christian & Martin; you should have an 
> automated email about it. I know Trac is not ideal (GitHub Issues is 
> nice) but we have all our ImageJ tickets in Trac now, migrating 
> everything would be very involved, and I don't really want to start 
> splitting between two issue trackers. Someday we might move...

@plugin jars
> > Are you planing to re-organize the plugins, e.g. such that plugins,
> > which are interesting for any application reside in their own
> > jar-file?
>
> This is probably a good idea. However, I agree with Lee that in some 
> cases it may not be totally clear-cut [1]. You think splitting 
> ij-commands into two JAR files is sufficient? If so, care to send a 
> list of plugins you feel are *not* generally useful, and I can split 
> them out?
We would definitly provide our help for the creation of such a list (at 
least we could look through the plugins and mark the ones that are
useful within KNIME) however it might be better to delay this until 
short before the final release (final set of plugins, stable plugin system).

@service order  => ticket filed
> Michael wrote:
> > we had to move ModuleService behind  MenuService in the constructor
> > call to avoid a null pointer during initialization
> > (onEvent(ModulesAddedEvent) was called before initialize).
>
> That is a bug, thanks for reporting. However, moving the module 
> service after the menu service will not work because MenuService needs 
> CommandService which needs ModuleService.
>
> What's weird to me is, I am not sure why we don't see this bug when 
> running the end-user ImageJ application...
>
> I have some service initialization changes pending on ImageJ's 
> startup-speed branch, which may affect this. So we should debug 
> further once that branch is merged. Please feel free to file a Trac 
> ticket for it and assign to me.
>
> Michael wrote:
> > Is there a defined service order?
>
> The order is defined by two things:
> 1) If a service has an @Parameter dependency on another service, the 
> dependency gets initialized first.
> 2) Otherwise, the "priority" property of the @Plugin annotation is 
> used to order service initialization.
>
> > ((So far, we have tons of ideas where we could do more things
> > together. Thank you in advance for answering all these questions ;) ))
>
@dimension selection
as discussed between christian and curtis we will open a ticket with a 
better explenation for this issue



Thanks again for awnsering our questions
Regards

Christian, Martin, Michael



p.s.
>
> [1] You know what that easter egg does, right? Don't you *want* to 
> generate ASCII images using KNIME??? I know I do!
(-: of course we want. But we don't support getChannelMax/Min atm. so in 
KNIME its only for skilled programmers

++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++o#++++++++
+++++++++++++++++++++++++++++++++++++++O##O+++++++
+++++++++++++++++++++++++++++++++++++o#####o++++++
++++++++++++++++++++++++++++++++++++########++++++
++++++++++++++++++++++++++++++++++o##########+++++
+++++++++++++++++++++++++++++++++############+++++
+++++++++++++++++++++++++++++++o###########o++++++
++++++++++++++++++++++++++++++############++++++++
+++++++++#++++++++++++++++++o###########o+++++++++
++++++++###o+++++++++++++++############+++++++++++
+++++++O####o++++++++++++o###########o++++++++++++
++++++o######O++++++++++############++++++++++++++
+++++o#########+++++++*###########o+++++++++++++++
++++++##########+++++############+++++++++++++++++
+++++++##########o+*###########o++++++++++++++++++
++++++++O#####################++++++++++++++++++++
+++++++++*##################o+++++++++++++++++++++
++++++++++o###############O+++++++++++++++++++++++
+++++++++++o#############o++++++++++++++++++++++++
+++++++++++++##########O++++++++++++++++++++++++++
++++++++++++++########o+++++++++++++++++++++++++++
+++++++++++++++######+++++++++++++++++++++++++++++
++++++++++++++++###o++++++++++++++++++++++++++++++
++++++++++++++++o#++++++++++++++++++++++++++++++++

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20130703/e9e74091/attachment-0001.html>