Re: ImageJ development involvement/contributions

Posted by Raymond Martin-2 on Dec 10, 2009; 5:52am
URL: http://imagej.273.s1.nabble.com/ImageJ-development-involvement-contributions-tp3690030p3690070.html

Hi Grant,

> I agree entirely with Albert.  As some of you know, I've been working on a
> refactoring of ImageJ that doesn't force you to choose between Swing and
> AWT, but rather decouples the GUI components from the rest of the
> application.

I would like to see some of that before I get along too far in going from AWT
to Swing. Right now I am merely replacing functionality in a very simple
manner. Which is more of a proof-of-concept that it can be done without
severe drawbacks. After which I was intending to look into separating the
GUI from the engine part. I would be interested to see if we can work together
on this part.

In going from AWT to Swing I think perhaps it is not realized that it is not
as serious a transition as some seem to think. The screenshots I linked to in
an earlier post show this. It may have been seen as more serious in the past
where certain functionality was broken on some platforms. As things move
forward Java has improved on all the major platforms, so these problems are in
most cases a thing of the past. Where there are issues others have created
solutions or it can be solved.

It is much more of a smooth transition than a drastic level shift.

> I believe that this can be done in a way that requires only
> trivial changes to existing plugins while opening up many new
>  possibilities.

So far I have not had to make any changes to plugins to get them to work
with my AWT2Swing version. The changes are only occurring in the main
application. As far as I can tell, issues that occur are on the side of the
plugins alone. That is, those plugins are doing things that do not work with
ImageJ 100% and not the other way around.

>  In addition to accommodating AWT, Swing, GWT, and QT, as
>  Albert mentioned, I'm also considering how to make it possible to strap
>  ImageJ functionality into a rich cient platform, e.g. Eclipse RCP or
>  NetBeans Platform.  For instance, here is a big list of NetBeans Platform
>  applications:

For a somewhat smaller application like ImageJ the addition of large extra
libraries or code that is not portable between different development
environments is a disadvantage. This is what will happen if development is
done with platforms like Eclipse or NetBeans. And it sort of vacates the idea
of keeping things separated more, like in the case of the GUI, core
processing, plugins, etc.

With a simple Ant build file and reasonable sized external libraries, where
needed, development can be done with a simple editor and command line, or
opened in Eclipse, NetBeans, JDeveloper, and so forth. To go with one of those
IDE for core development will be vendor lock-in (a software engineering anti-
pattern) for developers, which is a severe red flag to me in regards to free
software development.

It might be okay for a proprietary application, with a captive in-house team,
to settle on one environment, but it is largely inappropriate for an
application that has distributed development. There is no one-size-fits-all in
this case and it would be near impossible to force everyone to use one
environment besides the most basic core tools like a JDK and Ant. If certain
developers want to use those tools they should be free to use them, as long as
it does not prevent others from using the tools they want to use also.

I have tried NetBeans when it was at a few different versions. Not impressed.
I used Eclipse for more than a year. Okay, but bloat and other things started
to annoy me. I dabbled with JDeveloper. More of the same. I even used
KDevelop, which actually was not too bad (acts basically as an advanced editor
and runs the Ant build file). Now I mostly stick with a good editor and a
shell. It is the only way to keep really detailed control over the whole
process and nothing beats grep for searching in the code base.

Regards,

Raymond