Hi Michael,<div><br></div><div>Sorry to hear that the POM version detection is not working for KNIME. If the problem is *only* with the deprecated static VERSION, we plan to eliminate that soon anyway. But if the ImageJ#getVersion() method always returns null, that is a bad thing and we will need to fix it.</div>
<div><br></div><div>To debug this, I would need to set up a KNIP developer environment on my machine here so that I can reproduce and debug the issue. Are there instructions for doing that online?</div><div><br></div><div>
Thanks,</div><div>Curtis</div><div><br></div><div>P.S. Please CC imagej-devel on replies. Sometimes other developers may reply more quickly than I do, so it may save you time.<br><br><br><div class="gmail_quote">On Mon, Sep 17, 2012 at 2:15 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Hi Curtis,<br>
<br>
thanks for your reply and the explenation. Unfortunately I have
already a new issue. We tried to migrate the KNIME Image Extension<br>
to the beta 4 version of ImageJ and we have some problems with the
introduced integration of the POM file. The getPOM method<br>
does not work in the plugin/eclipse environment that is used by
KNIME I think this might be related to some OSGI stuff having
separate<br>
class loaders for each plugin...<br>
In any case getPOM does not find the POM file although it is
packed into the ImageJ jar file. Especially the static loading of
the version number causes therefore some problems for us.<br>
<br>
/** @deprecated Use {@link ImageJ#getVersion()} instead. */<br>
@Deprecated<br>
public static final String VERSION = POM.getPOM(ImageJ.class,
"net.imagej", "ij-core").getVersion();<br>
<br>
Do you have an idea how this could be resolved?<br>
<br>
Best regards,<br>
Michael<br>
<br>
</div><div><div class="h5">
<blockquote type="cite">Hi Michael,
<div><br>
</div>
<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"><br>
There seems to be an issue with the InputHarvester and the
SwingPanel if the object types of primitive java types are used
as input parameters (e.g. Boolean instead of boolean).</blockquote>
<div><br>
</div>
<div>Sorry for the delay in my reply. I fixed the bug shortly
after sending my first mail, but was waiting to reply back until
I did some more thorough investigation of the widget framework.</div>
<div><br>
</div>
<div>In short, the NPE is fixed, and both plugins will work now.</div>
<div><br>
</div>
<div>The long story is that despite that, there is one remaining
issue of sorts with certain types of widgets. The toggle widget
(with big B Booleans) is one of them, and the choice widget is
another. The issue is that in some cases, the widget is not
totally capable of reflecting the model state.</div>
<div><br>
</div>
<div>In the case of Boolean, the widget model may begin with a
null value, but the toggle widget is only capable of displaying
false or true. It will display unchecked for null, and if the
user presses OK right away, the Boolean will be null (the widget
changes nothing right now). But if you check and then uncheck
the box again, the parameter value goes from null to true, and
then from true to false. There is no way to set it back to null.</div>
<div><br>
</div>
<div>In the case of the choice widget, the model may begin with a
value that is not on the list of allowed choices (again, null in
particular is a big offender here). The choice widget
immediately constrains the dropdown box to the first item on the
list and overwrites the model. So the widget ends up being the
reason the parameter doesn't end up with an (invalid) null
value.</div>
<div><br>
</div>
<div>This behavior is inconsistent, and ideally the model itself
would enforce value constraints, and the widgets would not
overwrite them.</div>
<div><br>
</div>
<div>However, given the amount of time needed to correct this
admittedly rather trivial inconsistency/deficiency, we are not
going to worry about it for the time being.</div>
<div><br>
</div>
<div>Please let us know if you have any other questions or
problems with ImageJ2!</div>
<div><br>
</div>
<div>Regards,</div>
<div>Curtis</div>
<div><br>
</div>
<div><br>
<div class="gmail_quote">On Thu, Aug 23, 2012 at 9:57 AM, Curtis
Rueden <span dir="ltr"><<a href="mailto:ctrueden@wisc.edu" target="_blank">ctrueden@wisc.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Michael,
<div>
<div><br>
</div>
<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">
<br>
There seems to be an issue with the InputHarvester and
the SwingPanel if the object types of primitive java
types are used as input parameters (e.g. Boolean instead
of boolean).</blockquote>
<div><br>
</div>
</div>
<div>Thanks for the report. It's definitely a bug due to our
recent refactoring of the widget system. Both Boolean and
boolean are supposed to work. I'll look into fixing it
today.</div>
<span><font color="#888888">
<div>
<br>
</div>
<div>-Curtis</div>
</font></span>
<div><br>
</div>
<div>P.S. Hopefully I will have time to respond to your
ImgLib mail from yesterday, too. I really appreciate you
taking the time to look at and improve the Projector
logic. We did the minimum necessary at the time to get
something working, but currently everything is planar, and
there is no built-in (i.e., ImgLib2) zoom capability,
which we will eventually need.</div>
<div>
<div>
<div><br>
</div>
<div><br>
<div class="gmail_quote">On Thu, Aug 23, 2012 at 8:24
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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Hi Curtis,<br>
<br>
I try currently to integrate the new imglib and
ImageJ2 version (stuff from yesterday) into the
KNIME ImageJ2 plugin.<br>
There seems to be an issue with the
InputHarvester and the SwingPanel if the object
types of primitive java types are<br>
used as input parameters (e.g. Boolean instead
of boolean).<br>
<br>
The following plugin works fine:<br>
<br>
<small><small>@Plugin(menu = {@Menu(label =
"works")},<br>
headless=true)<br>
public class Working<T extends
RealType<T>> implements
RunnablePlugin {<br>
<br>
@Parameter(type = ItemIO.INPUT)<br>
private boolean test;<br>
<br>
@Parameter(type = ItemIO.OUTPUT)<br>
private String output;<br>
<br>
public void run() {<br>
if (test) {<br>
output = "plugins can be
defined as fragments of imagej.core";<br>
}<br>
}<br>
<br>
}<br>
<br>
<br>
</small></small>while this plugin (Boolean
instead of boolean) cannot be executed and
results in a null pointer exception.<br>
<br>
<br>
<small><small>@Plugin(menu = {@Menu(label =
"works not")},<br>
headless=true)<br>
public class NotWorking<T extends
RealType<T>> implements
RunnablePlugin {<br>
<br>
@Parameter(type = ItemIO.INPUT)<br>
private Boolean test;<br>
<br>
@Parameter(type = ItemIO.OUTPUT)<br>
private String output;<br>
<br>
public void run() {<br>
if (test) {<br>
output = "plugins can be
defined as fragments of imagej.core";<br>
}<br>
}<br>
<br>
}</small></small><br>
<br>
Are only primitive types supported or is it a
bug?<br>
<br>
Regards<span><font color="#888888"><br>
Michael<br>
</font></span></div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>