<div dir="ltr">Hi Michael, Christian, Martin,<div><br></div><div><div>> I just worked through the "code question" (version, context, ...)</div><div>> everything seems to work again.</div></div><div><br></div>
<div style>Excellent, glad to hear!</div><div style><br></div><div><div><div>> Without a (hacky) checkbox we would end up with simply not calling</div><div>> preview() on Previewable commands. Additionally we could also change</div>
<div>> this if we wanted to support previews in the future.</div></div></div><div><br></div><div>I filed a ticket to remove all "Preview" checkbox parameters:</div><div> <a href="http://trac.imagej.net/ticket/1952" target="_blank">http://trac.imagej.net/ticket/1952</a><br>
</div><div><br></div><div>> @dynamic command detection => ticket filed</div><div><br></div><div>Thanks, Michael! For lurkers, the ticket is:</div><div> <a href="http://trac.imagej.net/ticket/1933" target="_blank">http://trac.imagej.net/ticket/1933</a></div>
<div><br></div><div><div>> We would definitly provide our help for the creation of such a list</div><div>> (at least we could look through the plugins and mark the ones that are</div><div>> useful within KNIME) however it might be better to delay this until</div>
<div>> short before the final release (final set of plugins, stable plugin</div><div>> system).</div><div><br></div><div>Great. I filed a ticket for it, slated for 2.0.0 final release:</div><div> <a href="http://trac.imagej.net/ticket/1953" target="_blank">http://trac.imagej.net/ticket/1953</a></div>
<div><br></div></div><div>> @service order => ticket filed</div><div><br></div><div>Thanks! That ticket is at:</div><div> <a href="http://trac.imagej.net/ticket/1934" target="_blank">http://trac.imagej.net/ticket/1934</a></div>
<div><br></div><div>And I already fixed it. ;-)</div><div><br></div><div><div>> @dimension selection as discussed between christian and curtis we will</div><div>> open a ticket with a better explenation for this issue</div>
<div><br></div><div>Christian did file a ticket for it, which is at:</div><div> <a href="http://trac.imagej.net/ticket/1944">http://trac.imagej.net/ticket/1944</a></div><div><br></div><div style>It's a doozy, so I classified it as a "feature" and tentatively slated for 2.0.0 final release. We will need it for ImageJ2 to really behave compatibly with ImageJ1's slice-wise PluginFilters. But it will be a significant undertaking requiring some thought to get both the API and UI right.</div>
<div><br></div><div style>Thanks again for all the feedback and hard work, guys.</div><div><br></div><div>Regards,</div><div>Curtis</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 3, 2013 at 10:23 AM, Michael Zinsmaier <span dir="ltr"><<a href="mailto:michael.zinsmaier@gmx.de" target="_blank">michael.zinsmaier@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div 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<div><br>
<blockquote 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></div>
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<div><br>
<blockquote 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>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><br>
</div>
<div>Michael wrote:</div>
<div><span style="font-family:arial,sans-serif;font-size:13px">> Why
is the threshold plugin an interactive command?</span><br>
</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">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><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><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><font face="arial, sans-serif"><br>
</font></div>
<div><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><font face="arial, sans-serif"><br>
</font></div>
<div><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><font face="arial, sans-serif"><br>
</font></div>
<div><font face="arial, sans-serif">Lee wrote:</font></div>
<div><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>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>
</div><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<div><br>
<blockquote type="cite">
<div dir="ltr">
<div><font face="arial, sans-serif">Michael wrote:</font></div>
<div><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><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><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><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><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></div>
@plugin jars<div><br>
<blockquote type="cite">
<div dir="ltr">
<div>
<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></div>
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<div><br>
<blockquote type="cite">
<div dir="ltr">
<div>
<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><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><br>
</div>
<div><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></div>
@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.<div><br>
<blockquote type="cite">
<div dir="ltr">
<div><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></div>
(-: 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>
</div>
</blockquote></div><br></div></div>