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 class="im"><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 class="HOEnZb"><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 class="HOEnZb"><div class="h5">
<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>