<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Can we not, alternately, create a plugin that doesn't use
@Parameters? This is possible, is it not?<br>
I can imagine someone wanting to build a plugin that has some crazy
custom input widgets...<br>
<br>
Another idea... could there not be a way to intercept the InputPanel
after creation, modify it (and then one would need to intercept the
'harvesting' step ...).... Hmmm...<br>
<br>
<pre class="moz-signature" cols="72">Grant B. Harris
---------------------------------------------------------
Scientific Informatics Analyst, Cellular Dynamics Program
Marine Biological Laboratory, Woods Hole, Mass. 02543
<a class="moz-txt-link-abbreviated" href="mailto:gharris@mbl.edu">gharris@mbl.edu</a>
</pre>
<br>
On 6/20/2011 4:15 PM, Lee Kamentsky wrote:
<blockquote cite="mid:4dffaa6d.471c340a.4c2d.0e73@mx.google.com"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
I have a more-general mechanism in CellProfiler that lets you do
this kind of thing. The module (read ImageJ plugin) has a method
that returns a collection of settings. These are equivalent to the
parameters in ImageJ 2.0. You can restructure the collection
contextually in response to user events - for instance, there's a
"DoSomething" setting which is displayed as a button and it calls
a callback when the button is pressed. You can implement an "Add
another" button that changes the module's setting list in the
callback and the framework will ask for the settings again, with
the settings added by pressing the button.<br>
<br>
CellProfiler 1.0 had a fixed list and it felt like it was
arbitrarily limiting - you'd run into cases where you wanted four
of something, but provisions were there for only 3 slots.<br>
<br>
IMHO, unfortunately pretty far down the line to change the way
this works, but you could convince me otherwise.<br>
<br>
-- Lee<br>
<br>
On 6/20/2011 4:06 PM, Barry DeZonia wrote:
<blockquote
cite="mid:BANLkTimA+HOFGdV2jjA0SoRNNmKi-viu9A@mail.gmail.com"
type="cite">I have created a ticket to track this issue: <a
moz-do-not-send="true"
href="http://dev.imagejdev.org/trac/imagej/ticket/623">http://dev.imagejdev.org/trac/imagej/ticket/623</a>.
Note that it does not yet include anything from this discussion.<br>
<br>
In regards to the proposal note that I see that the issue is
more than just allowing us to populate choices and min/max at
runtime. In the ReorderAxes plugin I'd like to have 3 parameters
each of which has 3 choices for an XYZ Dataset. And 5 parameters
each with 5 choices for an XYCZT Dataset. So I should be able to
specify the number of parameters at runtime also. Or make the
plugin have the max possible but only enable and display/use a
subset of the parameters present.<br>
<br>
<div class="gmail_quote">On Mon, Jun 20, 2011 at 2:43 PM, Curtis
Rueden <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ctrueden@wisc.edu">ctrueden@wisc.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;"> Hi Grant, Barry et. al,<br>
<br>
At the meeting today we discussed how there is currently no
way to override an annotated parameter's min, max or choices
settings. It would be nice to be able to set them based on
the current state upon plugin execution.<br>
<br>
One way is to have option callback methods for min, max and
choices. So rather than a constant value, the min, max and
choices are computed by a method dynamically. For min and
max, there could be a notation like putting "#" in front of
the string to indicate it's a callback, since min and max of
Parameter are already strings. For choices, it's a String,
so you'd have to write it as: 'choices =
{"#nameOfCallback"}'.<br>
<br>
Do you think that's too awkward? Anyone have any better
ideas?<br>
<font color="#888888"><br>
-Curtis<br>
<br>
</font><br>
_______________________________________________<br>
ImageJ-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:ImageJ-devel@imagejdev.org">ImageJ-devel@imagejdev.org</a><br>
<a moz-do-not-send="true"
href="http://imagejdev.org/mailman/listinfo/imagej-devel"
target="_blank">http://imagejdev.org/mailman/listinfo/imagej-devel</a><br>
<br>
</blockquote>
</div>
<br>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
ImageJ-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:ImageJ-devel@imagejdev.org">ImageJ-devel@imagejdev.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://imagejdev.org/mailman/listinfo/imagej-devel">http://imagejdev.org/mailman/listinfo/imagej-devel</a>
</pre>
</blockquote>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
ImageJ-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ImageJ-devel@imagejdev.org">ImageJ-devel@imagejdev.org</a>
<a class="moz-txt-link-freetext" href="http://imagejdev.org/mailman/listinfo/imagej-devel">http://imagejdev.org/mailman/listinfo/imagej-devel</a>
</pre>
</blockquote>
</body>
</html>