<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Curtis,<br>
<br>
thanks for the reply, I just worked through the "code question"
(version, context, ...) everything seems to work again.<br>
Now for the other issues<br>
<br>
@preview checkboxes<br>
<blockquote
cite="mid:CADN69ykSz9rDS2Pp8Xnm9=yHNDakwEM+_m9Q8F6jebDfC_fjZg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Michael wrote:</div>
<div>
<div>> Would it be possible to add a flag that surpresses
previews checkboxes</div>
<div>> during dialog building?</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
I think the 2nd approach could be a good solution. Without a (hacky)
checkbox we would end up with simply not calling preview() on<br>
Previewable commands. Additionally we could also change this if we
wanted to support previews in the future.<br>
<br>
@interactive commands<br>
<blockquote
cite="mid:CADN69ykSz9rDS2Pp8Xnm9=yHNDakwEM+_m9Q8F6jebDfC_fjZg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Lee wrote:</div>
<div>
<div>> I hadn't looked at the interactive commands with
regard to</div>
<div>> CellProfiler. It looks like "buttons" could be
interpreted as possible</div>
<div> > headless actions that could be performed... at
least in some cases.</div>
<div><br>
</div>
<div style="">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.</div>
</div>
<div style=""><br>
</div>
<div style="">Michael wrote:</div>
<div style=""><span
style="font-family:arial,sans-serif;font-size:13px">> Why
is the threshold plugin an interactive command?</span><br>
</div>
<div style=""><span
style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div style=""><span
style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div style=""><span
style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div style=""><font face="arial, sans-serif">Anything that
extends InteractiveCommand should *not* be flagged with
"headless = true" since it is not intended for that purpose.</font></div>
<div style=""><font face="arial, sans-serif"><br>
</font></div>
<div style=""><font face="arial, sans-serif">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.</font></div>
<div style=""><font face="arial, sans-serif"><br>
</font></div>
<div style=""><font face="arial, sans-serif">This is not all
fully in place, but it is the direction we are going. </font><span
style="font-family:arial,sans-serif">Sound reasonable?</span></div>
<div style=""><font face="arial, sans-serif"><br>
</font></div>
<div style=""><font face="arial, sans-serif">Lee wrote:</font></div>
<div style=""><font face="arial, sans-serif">
<div>> For Threshold, I can see reasons for executing the
callbacks for</div>
<div>> "auto", "apply" and "delete" in a headless context</div>
<div><br>
</div>
<div style="">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.</div>
</font></div>
</div>
</blockquote>
<font face="arial, sans-serif">I</font>n our case the standalone
headless commands would end up as KNIME nodes and the interactive
meta command would be ignored.<br>
Which should work fine.<br>
<br>
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.<br>
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.<br>
<br>
<br>
@dynamic command detection => ticket filed<br>
<blockquote
cite="mid:CADN69ykSz9rDS2Pp8Xnm9=yHNDakwEM+_m9Q8F6jebDfC_fjZg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div style=""><font face="arial, sans-serif">Michael wrote:</font></div>
<div style=""><font face="arial, sans-serif">> </font><span
style="font-family:arial,sans-serif;font-size:13px">is there
a way to determine if a command is dynamic?</span></div>
<div style=""><span
style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div style=""><span
style="font-family:arial,sans-serif;font-size:13px">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...</span></div>
<div style=""><span
style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div style=""><span
style="font-family:arial,sans-serif;font-size:13px">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...</span></div>
</div>
</blockquote>
<br>
@plugin jars<br>
<blockquote
cite="mid:CADN69ykSz9rDS2Pp8Xnm9=yHNDakwEM+_m9Q8F6jebDfC_fjZg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div style="">
<div><font face="arial, sans-serif">> Are you planing to
re-organize the plugins, e.g. such that plugins,</font></div>
<div> <font face="arial, sans-serif">> which are
interesting for any application reside in their own</font></div>
<div><font face="arial, sans-serif">> jar-file?</font></div>
<div style="font-family:arial,sans-serif;font-size:13px"> <br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px">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?</div>
</div>
</div>
</blockquote>
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<br>
useful within KNIME) however it might be better to delay this until
short before the final release (final set of plugins, stable plugin
system).<br>
<br>
@service order => ticket filed<br>
<blockquote
cite="mid:CADN69ykSz9rDS2Pp8Xnm9=yHNDakwEM+_m9Q8F6jebDfC_fjZg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div style="">
<div style="font-family:arial,sans-serif;font-size:13px">
Michael wrote:</div>
<div>
<div><font face="arial, sans-serif">> we had to move
ModuleService behind MenuService in the constructor</font></div>
<div><font face="arial, sans-serif">> call to avoid a
null pointer during initialization</font></div>
<div><font face="arial, sans-serif">>
(onEvent(ModulesAddedEvent) was called before
initialize).</font></div>
<div><font face="arial, sans-serif"><br>
</font></div>
<div><span
style="font-family:arial,sans-serif;font-size:13px">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.</span><font face="arial, sans-serif"><br>
</font></div>
<div><span
style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13px">What's
weird to me is, I am not sure why we don't see this bug
when running the end-user ImageJ application...</span><br>
</div>
<div><span
style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div style=""><span
style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div style=""><br>
</div>
<div style=""><span
style="font-family:arial,sans-serif;font-size:13px">Michael
wrote:</span></div>
<div><font face="arial, sans-serif">> Is there a </font><span
style="font-family:arial,sans-serif">defined service
order?</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
</div>
<div style="font-family:arial,sans-serif;font-size:13px">The
order is defined by two things:</div>
<div style="font-family:arial,sans-serif;font-size:13px"> 1)
If a service has an @Parameter dependency on another
service, the dependency gets initialized first.</div>
<div style="font-family:arial,sans-serif;font-size:13px">2)
Otherwise, the "priority" property of the @Plugin annotation
is used to order service initialization.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div>
<div><font face="arial, sans-serif">> ((So far, we have
tons of ideas where we could do more things</font></div>
<div><font face="arial, sans-serif">> together. Thank you
in advance for answering all these questions ;) ))</font></div>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
</div>
</div>
</div>
</blockquote>
@dimension selection<br>
as discussed between christian and curtis we will open a ticket with
a better explenation for this issue<br>
<br>
<br>
<br>
Thanks again for awnsering our questions<br>
Regards<br>
<br>
Christian, Martin, Michael<br>
<br>
<br>
<br>
p.s.<br>
<blockquote
cite="mid:CADN69ykSz9rDS2Pp8Xnm9=yHNDakwEM+_m9Q8F6jebDfC_fjZg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div style=""><br>
<div style="font-family:arial,sans-serif;font-size:13px">[1]
You know what that easter egg does, right? Don't you *want*
to generate ASCII images using KNIME??? I know I do!</div>
</div>
</div>
</blockquote>
(-: of course we want. But we don't support getChannelMax/Min atm.
so in KNIME its only for skilled programmers<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++<br>
++++++++++++++++++++++++++++++++++++++++o#++++++++<br>
+++++++++++++++++++++++++++++++++++++++O##O+++++++<br>
+++++++++++++++++++++++++++++++++++++o#####o++++++<br>
++++++++++++++++++++++++++++++++++++########++++++<br>
++++++++++++++++++++++++++++++++++o##########+++++<br>
+++++++++++++++++++++++++++++++++############+++++<br>
+++++++++++++++++++++++++++++++o###########o++++++<br>
++++++++++++++++++++++++++++++############++++++++<br>
+++++++++#++++++++++++++++++o###########o+++++++++<br>
++++++++###o+++++++++++++++############+++++++++++<br>
+++++++O####o++++++++++++o###########o++++++++++++<br>
++++++o######O++++++++++############++++++++++++++<br>
+++++o#########+++++++*###########o+++++++++++++++<br>
++++++##########+++++############+++++++++++++++++<br>
+++++++##########o+*###########o++++++++++++++++++<br>
++++++++O#####################++++++++++++++++++++<br>
+++++++++*##################o+++++++++++++++++++++<br>
++++++++++o###############O+++++++++++++++++++++++<br>
+++++++++++o#############o++++++++++++++++++++++++<br>
+++++++++++++##########O++++++++++++++++++++++++++<br>
++++++++++++++########o+++++++++++++++++++++++++++<br>
+++++++++++++++######+++++++++++++++++++++++++++++<br>
++++++++++++++++###o++++++++++++++++++++++++++++++<br>
++++++++++++++++o#++++++++++++++++++++++++++++++++<br>
<br>
</body>
</html>