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#++++++++++++++++++++++++++++++++
_______________________________________________
ImageJ-devel mailing list
ImageJ-devel@imagej.net
http://imagej.net/mailman/listinfo/imagej-devel
