A Preliminary Document on Refactoring ImageJ for Extensibility

[Grant]

For anyone who is interested, I have posted a draft of preliminary
document on Refactoring ImageJ for Extensibility in the Files section
of ImageJX. It is not complete and my ideas are still in flux, but it
will hopefully provide some ideas. (I have actually done much of the
refactoring discussed in this document and am happy to share it with
anyone who is interested.)

Feedback is welcome.

-- Grant

[wil...@ieee.org]

My system seems to be missing some of the fonts used in the DOC. Could
you post a PDF instead?

Thanks,
Wilhelm

[Joris Meys]

Great document, thanks for the effort. I don't have enough experience
to make any valuable comment, but as an addition to the discussion I
would like to point out the wishlist on the ImageJ Wiki :

http://imagejdocu.tudor.lu/doku.php?id=wishlist:start

Kind regards
Joris

[Dimiter]

I was also thinking of extending the current plugin model.

I define an abstract class, which implements the original PlugIn
interface; then I inherit from this class and implement the necessary
methods.



Here is what I use in some of my plugins:

-------------------------------------------------------------
import ij.*;
import ij.plugin.*;

import java.util.Properties;

/**
* @author (C)Dimiter Prodanov
* IMEC
*
* @version 1.0 26 Oct 2008
*
* @contents This plugin draws projection of a stack.
*
* @license This library is free software; you can redistribute it and/
or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later
version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General
Public
* License along with this library; if not, write to the Free
Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA
*
*/
public abstract class APlugIn implements PlugIn {

/**
*
*/
public APlugIn() {
// TODO Auto-generated constructor stub
}

protected static void savePreferences(Properties prefs) {

}

protected boolean showDialog() {
return false;
}

protected void HelpMsg(int code) {

}

public static void main(String[] args) {

try {
System.setProperty("plugins.dir", args[0]);
new ImageJ();
}
catch (Exception ex) {
IJ.log("plugins.dir misspecified");
}

}
}
--------------------------------------------------------------

[Dimiter]

I think that before offering solutions
you should define the problems/issues. Once the community agrees on
the priorities in handling the issues the solutions would come out
very logically.

I don't see any clear definitions of the existing issues at this stage
in your proposal. Therefore, it is difficult to judge the suitability
of your solutions.

Cheers

Dimiter

[Adrian Daerr]

On 22 mar, 11:49, Dimiter <dimite...@gmail.com> wrote:
> I think that before offering solutions you should define the problems/issues.

I don't understand your criticism. Grant does point out that the
current design is unnecessarily restrictive, because extending classes
binds your implementation to those classes, and the framework they
live in (the GUI components and their ties with AWT are given as an
example). The other message you posted a few minutes before, where you
cite your own APlugIn class, is a good example of Grant's point. Why
should all plugins be forced to extend the APlugIn class, when you
could have defined an Interface instead and leave the plugins with the
liberty to inherit from some other class? For an almost entirely
abstract class such as yours, or a new hypothetical new PlugInX
interface, a better way to proceed consists in defining an interface
and possibly providing an abstract adapter class, along the lines of
what the java core classes do (Mouse*Listener/MouseAdapter etc). This
is less restrictive on the implementing code, and more easily
extensible.

This said many of the methods of your APlugIn class are interfaces I
miss strongly for current plugins, and agree they should be provided
for more usability, most notably a way to expose a help-page/usage of
the plugin, etc. Even within the current ImageJ, it would be nice to
add an interface for this (which is another example why using
interfaces makes a design so much easier to extend: plugins could
simply implement it *in addition* to PlugIn[Filter], and benefit from
the new feature).

cheers
--
Adrian

[Dimiter]

On Mar 24, 6:43 pm, Adrian Daerr <adrian.da...@gmx.de> wrote:
> On 22 mar, 11:49, Dimiter <dimite...@gmail.com> wrote:
>
> > I think that before offering solutions you should define the problems/issues.
>
> I don't understand your criticism.

I say that he/we should define a list of problems. The coupling to AWT
is one of them, I agree.

Grant does point out that the current design is unnecessarily
restrictive, because extending classes
> binds your implementation to those classes, and the framework they
> live in (the GUI components and their ties with AWT are given as an
> example). The other message you posted a few minutes before, where you
> cite your own APlugIn class, is a good example of Grant's point. Why
> should all plugins be forced to extend the APlugIn class, when you
> could have defined an Interface instead and leave the plugins with the
> liberty to inherit from some other class? For an almost entirely
> abstract class such as yours, or a new hypothetical new PlugInX
> interface, a better way to proceed consists in defining an interface
> and possibly providing an abstract adapter class, along the lines of
> what the java core classes do (Mouse*Listener/MouseAdapter etc). This
> is less restrictive on the implementing code, and more easily
> extensible.

You have a point here. But my choice was restricted by the current
ImageJ architecture.
Yet, which can be the other class which a PlugIn can inherit?

>
> This said many of the methods of your APlugIn class are interfaces I
> miss strongly for current plugins, and agree they should be provided
> for more usability, most notably a way to expose a help-page/usage of
> the plugin, etc. Even within the current ImageJ, it would be nice to
> add an interface for this (which is another example why using
> interfaces makes a design so much easier to extend: plugins could
> simply implement it *in addition* to PlugIn[Filter], and benefit from
> the new feature).

ImageJ totally lacks interactive help mechanism and I think that it is
a major obstacle for furhter development.
About the interfaces: Nothing stops you from defining your own
interfaces. The problem is that these interfaces will not be
recognized by the "core" ImageJ.
So when defining interfaces you should also specify behaviors in the
"core" ImageJ.
>
> cheers
> --
> Adrian
With my critique I don't want to impede the development but to provoke
more structured discussion.


cheers,

Dimiter

[Adrian Daerr]

> Yet, which can be the other class which a PlugIn can inherit?

A PlugIn might want to inherit from another class in another package
or library, or from a JFrame, or ... The main argument for interfaces
over inheritance is however that it is easy to add another interface,
while once you have fixed the contents of an abstract APlugIn class
that PlugIns have to extend, it is hard to change things without
breaking existing code.

> ImageJ totally lacks interactive help mechanism and I think that it is
> a major obstacle for furhter development.

agreed

> About the interfaces: Nothing stops you from defining your own
> interfaces. The problem is that these interfaces will not be
> recognized by the "core" ImageJ.

Well, they could. Why don't we ask Wayne to add a PlugInHelp interface
(is "interface PlugInHelp { String usage(); }" sufficient ?) and the
code to take advantage of it (i.e. if a PlugIn isInstance(PlugInHelp),
then add an entry in the 'about' menu which calls its usage() method
and displays the text in a window) ? The nicer solution would be some
hypertext help like javadoc, but even a primitive solution could
already encourage some documentation by PlugIn writers. I guess Wayne
would want a patch, I'll see if I find the time to write one down.

> With my critique I don't want to impede the development but to provoke
> more structured discussion.

Me too :). If my comment sounded harsh I apologize. I surely don't own
the truth about the Right Way To Do It !

--
Adrian