ImageJ development involvement/contributions

[Raymond Martin-2]

Hi,

I was just wondering what the situation is with development
involvement/contributions to the code for ImageJ.

I just got the code and started to upgrade some of the AWT stuff
to Swing. It compiles and runs okay (I can load an image, etc.).
Still more work to get rid of all the glitches, but it is a start.

I can contribute this work and more.

What is the project's position on this?

Thanks,

Raymond Martin

[Albert Cardona-2]

Hi Raymond,

> I was just wondering what the situation is with development
> involvement/contributions to the code for ImageJ.


Development for ImageJ affects thousands of users and is not a small matter.
A funded project is starting for the development of some identified
areas in need.
Most details are here:

http://imagejdev.org/


> I just got the code and started to upgrade some of the AWT stuff
> to Swing. It compiles and runs okay (I can load an image, etc.).
> Still more work to get rid of all the glitches, but it is a start.


About half a dozen developers have attempted that.
There are lots of issues involved, it's not a trivial matter of "upgrading".


> I can contribute this work and more.
>
> What is the project's position on this?


The best contribution is on image processing algorithms.
In particular algorithms with broad applications such as:

* image segmentation in 2D/3D/4D
* particle counting
* particle tracking

Hundreds of labs around the world would benefit from good, robust,
reliable, fast algorithm implementations of the above in all their flavors.

Albert

[Raymond Martin-2]

Hello Albert,

> > I was just wondering what the situation is with development
> > involvement/contributions to the code for ImageJ.
>
> Development for ImageJ affects thousands of users and is not a small
>  matter. A funded project is starting for the development of some
>  identified areas in need.
> Most details are here:
>
> http://imagejdev.org/

I already went to that site before joining this list and looked through every
page. Not much there to indicate what involvement might be permitted and
further documentation is not available or is missing.

>
> > I just got the code and started to upgrade some of the AWT stuff
> > to Swing. It compiles and runs okay (I can load an image, etc.).
> > Still more work to get rid of all the glitches, but it is a start.
>
> About half a dozen developers have attempted that.
> There are lots of issues involved, it's not a trivial matter of
>  "upgrading".

Really. I am not that half dozen developers and my attempt to "upgrade" the
Swing parts does work.It was rather trivial given my years of software
development experience working with Java, C/C++, etc.

> > I can contribute this work and more.
> >
> > What is the project's position on this?
>
> The best contribution is on image processing algorithms.
> In particular algorithms with broad applications such as:

Maybe my contribution cannot be among the best that you are
suggesting, but it could be something good that users might want.

Am I to gather that you are saying that my potential contributions are not
wanted?

Then again, I do not know what your relationship is to the project. Are
you in a position to speak on behalf of the project?

Regards,

Raymond

[Volker Baecker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Raymond,
welcome among the ImageJ users and developers and thank you for your
intention to contribute to the project and share code.

I'll try to explain how things are working here. Please note that this
is my personal point of view and that I have no official authority to
speak for anyone but myself.

ImageJ itself is developed by Wayne Rasband. He is the only authority
that decides what happens to it and which code will be integrated. The
result of his work is in the public domain and used by many research
groups around the world.

If you want to get code into the ImageJ base there are basically two ways:

- - your code is so important that you propose it to Wayne directly (per
email or via this list) and he decides to integrate it

- - You propose your code to the ImageJ community. If possible you make it
available for download as an ImageJ plugin or if necessary as an
alternative ImageJ version. You can put it on
http://imagejdocu.tudor.lu/doku.php or somewhere else and announce it in
this list. It can then be used this way for some time and prove its
value. If there is an interest to have it in the base product Wayne
might want to integrate it or use parts of it or rewrite the
functionality in a different way sooner or later. I think there are
quite some examples of code and ideas that started as plugins and became
integrated into the code.

There is a part of the ImageJ community that wants to make important
changes  to the code base in order to allow ImageJ to be used as a
library more easily and to have a better way to work with
multi-dimensional images. If you want to participate in these
discussions look at http://groups.google.com/group/imagejx

Now what concerns swing. That was really bad look that you started with
this ;-)
It has been discussed many times here. There is an important part of the
ImageJ community that is absolutely hostile against swing. I personally
don't understand why (I think these are mainly mac users and that swing
might have caused problems in older mac versions).
On the other hand this is not so much of a problem since you can always
use swing for your own plugins / or imagej based tools even if the
ImageJ base windows are not using it.

Best regards,
Volker Bäcker

Raymond Martin wrote:

> Hello Albert,
>
>>> I was just wondering what the situation is with development
>>> involvement/contributions to the code for ImageJ.
>> Development for ImageJ affects thousands of users and is not a small
>>  matter. A funded project is starting for the development of some
>>  identified areas in need.
>> Most details are here:
>>
>> http://imagejdev.org/
>
> I already went to that site before joining this list and looked through every
> page. Not much there to indicate what involvement might be permitted and
> further documentation is not available or is missing.
>
>>> I just got the code and started to upgrade some of the AWT stuff
>>> to Swing. It compiles and runs okay (I can load an image, etc.).
>>> Still more work to get rid of all the glitches, but it is a start.
>> About half a dozen developers have attempted that.
>> There are lots of issues involved, it's not a trivial matter of
>>  "upgrading".
>
> Really. I am not that half dozen developers and my attempt to "upgrade" the
> Swing parts does work.It was rather trivial given my years of software
> development experience working with Java, C/C++, etc.
>
>>> I can contribute this work and more.
>>>
>>> What is the project's position on this?
>> The best contribution is on image processing algorithms.
>> In particular algorithms with broad applications such as:
>
> Maybe my contribution cannot be among the best that you are
> suggesting, but it could be something good that users might want.
>
> Am I to gather that you are saying that my potential contributions are not
> wanted?
>
> Then again, I do not know what your relationship is to the project. Are
> you in a position to speak on behalf of the project?
>
> Regards,
>
> Raymond
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksXkmYACgkQ0gXPLVKexCfWcgCfabHUaRGpuZ50LVZ3C5V+Kv6P
ULAAn2RBq6MZ8N939gGR+EJj7ICJrPGX
=XauB
-----END PGP SIGNATURE-----

--
passerelle antivirus du campus CNRS de Montpellier
--

[dscho]

Hi Raymond,

welcome to ImageJ.

On Wed, 2 Dec 2009, Raymond Martin wrote:

> > > I just got the code and started to upgrade some of the AWT stuff to
> > > Swing. It compiles and runs okay (I can load an image, etc.). Still
> > > more work to get rid of all the glitches, but it is a start.
> >
> > About half a dozen developers have attempted that. There are lots of
> > issues involved, it's not a trivial matter of
> >  "upgrading".
>
> Really. I am not that half dozen developers and my attempt to "upgrade" the
> Swing parts does work.It was rather trivial given my years of software
> development experience working with Java, C/C++, etc.

Unfortunately, I have to agree with Albert that it is very unfortunate you
picked the "upgrading" of AWT to Swing as your subject.

The problem why the half-dozen developers (that very much includes
you!) fail is that it is not enough to think about ImageJ as a stand-alone
program.

If ImageJ was a stand-alone program, you would be totally correct, you
could just "fix" things by replacing all AWT with Swing components.

The problem is that ImageJ is not a stand-alone program.

One of the most powerful aspects of ImageJ is its extensibility by
plugins.  To ignore plugins is like saying that a Mercedes is essentially
the engine.

As it happens, many plugins use the public API of ImageJ extensively, and
many rely on that part of the API which returns AWT object instances.

So in effect, your "upgrade" would break the most powerful plugins.  (I
think that is what Volker meant to say: users are kind of unforgiving when
something stops working they rely on.)

> Maybe my contribution cannot be among the best that you are
> suggesting, but it could be something good that users might want.

It might have been a good idea to communicate your idea to replace the AWT
components with Swing components earlier; I could have pointed you to at
least two publically available versions of ImageJ using Swing instead of
AWT.

> Am I to gather that you are saying that my potential contributions are
> not wanted?

All potential contributions are wanted.  But some are desired only by part
of the users.

Albert listed some of the potential contributions that are likely to make
you extremely popular.

> Then again, I do not know what your relationship is to the project. Are
> you in a position to speak on behalf of the project?

I take this as the more general question "who is in charge of ImageJ, and
how does Open Source work?".  The answer to the first part is: Wayne
Rasband.  You can get this information even from WikiPedia.

The second part of the question can be answered like this: you can do
whatever you want/need to do.  It is very nice if you let other people
know what you did, and benefit from your work.

With ImageJ in particular, most contributions come in the form of a plugin
that is either linked on a website or sent as source code to this mailing
list.

Sometimes, changes in ImageJ are made -- but make sure that they do not
break existing workflows!  These changes are most often sent directly to
Wayne, but sometimes they are sent to this mailing list.

The advantage of sending your work to the mailing list is not only that
you earn respect, but also that you can benefit from the biggest upside of
Open Source: there is always some more experienced software developer out
there from whose comments your code can benefit.

Ciao,
Johannes

[Raymond Martin-2]

Hi Volker,

Thanks for the information. I will certainly look into this further to see
where I can best contribute and what the pitfalls are.

Best regards,

Raymond

On December 3, 2009 05:26:54 am Volker Baecker wrote:

> Hello Raymond,
> welcome among the ImageJ users and developers and thank you for your
> intention to contribute to the project and share code.
>
> I'll try to explain how things are working here. Please note that this
> is my personal point of view and that I have no official authority to
> speak for anyone but myself.
>
> ImageJ itself is developed by Wayne Rasband. He is the only authority
> that decides what happens to it and which code will be integrated. The
> result of his work is in the public domain and used by many research
> groups around the world.
>
> If you want to get code into the ImageJ base there are basically two ways:
>
> - your code is so important that you propose it to Wayne directly (per
> email or via this list) and he decides to integrate it
>
> - You propose your code to the ImageJ community. If possible you make it
> available for download as an ImageJ plugin or if necessary as an
> alternative ImageJ version. You can put it on
> http://imagejdocu.tudor.lu/doku.php or somewhere else and announce it in
> this list. It can then be used this way for some time and prove its
> value. If there is an interest to have it in the base product Wayne
> might want to integrate it or use parts of it or rewrite the
> functionality in a different way sooner or later. I think there are
> quite some examples of code and ideas that started as plugins and became
> integrated into the code.
>
> There is a part of the ImageJ community that wants to make important
> changes  to the code base in order to allow ImageJ to be used as a
> library more easily and to have a better way to work with
> multi-dimensional images. If you want to participate in these
> discussions look at http://groups.google.com/group/imagejx
>
> Now what concerns swing. That was really bad look that you started with
> this ;-)
> It has been discussed many times here. There is an important part of the
> ImageJ community that is absolutely hostile against swing. I personally
> don't understand why (I think these are mainly mac users and that swing
> might have caused problems in older mac versions).
> On the other hand this is not so much of a problem since you can always
> use swing for your own plugins / or imagej based tools even if the
> ImageJ base windows are not using it.
>
> Best regards,
> Volker Bäcker

[Raymond Martin-2]

Hi Johannes,

> welcome to ImageJ.

Thanks.

> On Wed, 2 Dec 2009, Raymond Martin wrote:
> > > > I just got the code and started to upgrade some of the AWT stuff to
> > > > Swing. It compiles and runs okay (I can load an image, etc.). Still
> > > > more work to get rid of all the glitches, but it is a start.
> > >
> > > About half a dozen developers have attempted that. There are lots of
> > > issues involved, it's not a trivial matter of
> > >  "upgrading".
> >
> > Really. I am not that half dozen developers and my attempt to "upgrade"
> > the Swing parts does work.It was rather trivial given my years of
> > software development experience working with Java, C/C++, etc.
>
> Unfortunately, I have to agree with Albert that it is very unfortunate you
> picked the "upgrading" of AWT to Swing as your subject.
>
> ...

From what you have written, I will be sure to make my code backwards
compatible with AWT plugins, as well as providing an upgraded Swing
UI and facility for newer Swing plugins. It is quite doable in my opinion.

I think I will just let my work speak for itself and post back when I have
worked it out. Unless someone else has other information that might
be helpful towards this end I will leave it at that for now.

Kind regards,

Raymond Martin

[dscho]

Hi Raymond,

On Thu, 3 Dec 2009, Raymond Martin wrote:

> > On Wed, 2 Dec 2009, Raymond Martin wrote:
> > > > > I just got the code and started to upgrade some of the AWT stuff
> > > > > to Swing. It compiles and runs okay (I can load an image, etc.).
> > > > > Still more work to get rid of all the glitches, but it is a
> > > > > start.
> > > >
> > > > About half a dozen developers have attempted that. There are lots
> > > > of issues involved, it's not a trivial matter of
> > > >  "upgrading".
> > >
> > > Really. I am not that half dozen developers and my attempt to
> > > "upgrade" the Swing parts does work.It was rather trivial given my
> > > years of software development experience working with Java, C/C++,
> > > etc.
> >
> > Unfortunately, I have to agree with Albert that it is very unfortunate
> > you picked the "upgrading" of AWT to Swing as your subject.
> >
> > ...
>
> From what you have written, I will be sure to make my code backwards
> compatible with AWT plugins, as well as providing an upgraded Swing UI
> and facility for newer Swing plugins. It is quite doable in my opinion.

There is a real problem in that ImagePlus' getCanvas() returns an instance
of ImageCanvas, which extends an AWT canvas.  And this is just the
beginning of the dependency on AWT.

> I think I will just let my work speak for itself and post back when I
> have worked it out. Unless someone else has other information that might
> be helpful towards this end I will leave it at that for now.

I really look forward to your work!

Ciao,
Johannes

[Raymond Martin-2]

Hi Johannes,

> > From what you have written, I will be sure to make my code backwards
> > compatible with AWT plugins, as well as providing an upgraded Swing UI
> > and facility for newer Swing plugins. It is quite doable in my opinion.
>
> There is a real problem in that ImagePlus' getCanvas() returns an instance
> of ImageCanvas, which extends an AWT canvas.  And this is just the
> beginning of the dependency on AWT.

Yes, I encountered this during my preliminary hacking of ImageJ. In the end,
it is no problem at all. My version compiles, runs and opens images correctly
using Swing replacements despite ImageCanvas still inheriting from an AWT
Canvas.

They coexist happily at this point. Still need to check into plugins to see if
I have broken them in the process. It's a start.

I am also looking into ImageJX to see what the possibilities are.

Cheers,

Raymond

[dscho]

Hi,

On Thu, 3 Dec 2009, Raymond Martin wrote:

> > > From what you have written, I will be sure to make my code backwards
> > > compatible with AWT plugins, as well as providing an upgraded Swing
> > > UI and facility for newer Swing plugins. It is quite doable in my
> > > opinion.
> >
> > There is a real problem in that ImagePlus' getCanvas() returns an
> > instance of ImageCanvas, which extends an AWT canvas.  And this is
> > just the beginning of the dependency on AWT.
>
> Yes, I encountered this during my preliminary hacking of ImageJ. In the
> end, it is no problem at all. My version compiles, runs and opens images
> correctly using Swing replacements despite ImageCanvas still inheriting
> from an AWT Canvas.

Do you mean to say that ImageCanvas extends java.awt.Canvas, not
javax.swing.JPanel?  Then I understand why it works, but have to caution
that things do not work flawlessly everywhere.  At least in one instance,
AWT inside a Swing container did not work as expected: Linux with the
default window manager of GNOME (the repainting was sometimes correct,
sometimes not).

Ciao,
Johannes

[Raymond Martin-2]

Hi,

> Do you mean to say that ImageCanvas extends java.awt.Canvas, not
> javax.swing.JPanel?

Yes, presently.

> Then I understand why it works, but have to caution that things do not work
> flawlessly everywhere.  At least in one instance, AWT inside a Swing
> container did not work as expected: Linux with the default window manager of
> GNOME (the repainting was sometimes correct, sometimes not).

Okay, I will have to test that out at some point. I am on Linux, but using
Enlightenment as my default window manager.

Regards,

Raymond

[Michael Schmid]

Hi Volker, Raymond,

the preference of AWT instead of Swing might be strange for Java  
aficionados, but having the look and feel of the operating system  
(Windows, Mac, or whatever Window manager) makes life easier, not  
only for the average user but also for 'power users' who  
subconsciously recognize the buttons, highlighted input fields, etc.  
are if they have the usual appearance.
An example of the Swing GUI that has found its way into ImageJ is  
Plugins>Utilities>Find Commands. On Windows the buttons are so dull  
that one has to look twice to recognize them as such.

In addition, there are special and very useful operating system  
features that get lost with Swing. E.g., on the Mac one can drag and  
drop of files and folders from the "Finder" (Mac name for "File  
Manager") into open or save dialogs. Losing this would make me (and  
other Mac users) very hostile against Swing.

On the other hand, the user does not care about the inner workings of  
ImageJ. Making things less dependent on the GUI is, in principle, a  
good idea. ImageJ has started more than 10 years ago as a small Java  
applet, probably without the expectation that it would grow so much  
and be also used differently than in interactive mode; with these  
prospects at the beginning it would probably have a different design.
Concerning such changes at the current stage, the main problem is  
preserving compatibility with plugins - I guess that there are  
thousands of them, and many rely heavily on the internal structure.


So far a personal view,

Michael
________________________________________________________________

On 3 Dec 2009, at 11:26, Volker Baecker wrote:

(...)

> Now what concerns swing. (...)
> It has been discussed many times here. There is an important part  
> of the
> ImageJ community that is absolutely hostile against swing. I  
> personally
> don't understand why (I think these are mainly mac users and that  
> swing
> might have caused problems in older mac versions).
> On the other hand this is not so much of a problem since you can  
> always
> use swing for your own plugins / or imagej based tools even if the
> ImageJ base windows are not using it.

(...)

[simon andrews (BI)]

On 4 Dec 2009, at 11:29, Michael Schmid wrote:

> Hi Volker, Raymond,
>
> the preference of AWT instead of Swing might be strange for Java
> aficionados, but having the look and feel of the operating system
> (Windows, Mac, or whatever Window manager) makes life easier, not
> only for the average user but also for 'power users' who
> subconsciously recognize the buttons, highlighted input fields, etc.
> are if they have the usual appearance.

You can set a global setting to give all swing objects a native system  
look and feel.  We've done this with our applications for ages and  
virtually all of our Mac users think they're using a native Mac  
application.  With a command line addition you can even move the menu  
bar to the top of the screen.


> In addition, there are special and very useful operating system
> features that get lost with Swing. E.g., on the Mac one can drag and
> drop of files and folders from the "Finder" (Mac name for "File
> Manager") into open or save dialogs. Losing this would make me (and
> other Mac users) very hostile against Swing.

I've just checked, and with the native look and feel set within Swing  
then you can do this for JFileChooser as well.  There's also nothing  
stopping you from using the AWT file chooser whilst moving the main  
display windows to Swing.


> On the other hand, the user does not care about the inner workings of
> ImageJ. Making things less dependent on the GUI is, in principle, a
> good idea. ImageJ has started more than 10 years ago as a small Java
> applet, probably without the expectation that it would grow so much
> and be also used differently than in interactive mode; with these
> prospects at the beginning it would probably have a different design.
> Concerning such changes at the current stage, the main problem is
> preserving compatibility with plugins - I guess that there are
> thousands of them, and many rely heavily on the internal structure.

If we're still talking about Swing vs AWT then none of the core data  
structures (ImagePlus, ImageProcessor etc) need change at all.  It's  
only the front end which would update (ImageCanvas etc).  It's  
actually a really small change to convert these over to Swing since  
there are Swing equivalents to all of the core AWT components.  I've  
made an ImagePanel derivative of ImageCanvas for some of our  
applications and there are only about 10 lines of code which need to  
be changed to make the switch.  Remember that all swing objects  
inherit from an underlying AWT object so nearly all existing method  
calls will just transfer across.

I'm not saying that it's worth doing the switch between AWT and Swing,  
but it's maybe not such as big switch as is being made out (and I'm  
certainly not volunteering to do it :-)

TTFN

Simon.

> ________________________________________________________________
>
> On 3 Dec 2009, at 11:26, Volker Baecker wrote:
>
> (...)
>> Now what concerns swing. (...)
>> It has been discussed many times here. There is an important part
>> of the
>> ImageJ community that is absolutely hostile against swing. I
>> personally
>> don't understand why (I think these are mainly mac users and that
>> swing
>> might have caused problems in older mac versions).
>> On the other hand this is not so much of a problem since you can
>> always
>> use swing for your own plugins / or imagej based tools even if the
>> ImageJ base windows are not using it.
> (...)

[dscho]

Hi Simon,

On Fri, 4 Dec 2009, Simon Andrews wrote:

> On 4 Dec 2009, at 11:29, Michael Schmid wrote:
>
> >On the other hand, the user does not care about the inner workings of
> >ImageJ. Making things less dependent on the GUI is, in principle, a
> >good idea. ImageJ has started more than 10 years ago as a small Java
> >applet, probably without the expectation that it would grow so much and
> >be also used differently than in interactive mode; with these prospects
> >at the beginning it would probably have a different design. Concerning
> >such changes at the current stage, the main problem is preserving
> >compatibility with plugins - I guess that there are thousands of them,
> >and many rely heavily on the internal structure.
>
> If we're still talking about Swing vs AWT then none of the core data
> structures (ImagePlus, ImageProcessor etc) need change at all.

This is not true, as both have references to AWT components in them
(e.g. ImagePlus points to its ImageWindow, ImageProcessor points to the
Roi which points to the ImageCanvas, etc).

> I've made an ImagePanel derivative of ImageCanvas for some of our
> applications and there are only about 10 lines of code which need to be
> changed to make the switch.

For the SIOX plugin, Ignacio and me tried to decouple the ImagePlus from
the ImageCanvas, and use JImagePanel, but we failed to decouple the ROIs
enough: if the ImageProcessor is not attached to an ImageCanvas, then
there is currently no clean way to let ImageJ handle the ROIs but display
them as overlays of the JImagePanel.

> Remember that all swing objects inherit from an underlying AWT object so
> nearly all existing method calls will just transfer across.

There are subtle exceptions to this rule: for example, JPanel does not
extend the AWT-equivalent Canvas.  The painting rules are slightly
different.  In an AWT Frame, you add components using add(component), in
JFrame instances you have to use getContentPane().add(component).

All in all, Swing is just different enough to make an "upgrading" path
enough of a pain that all endeavors so far failed.

Note: It would be nice to be able to use Swing instead of AWT, as AWT's
limitations are quite real.  But I have to caution everybody who says that
it is easy, because that is not correct.

Ciao,
Johannes

[Raymond Martin-2]

Hi Michael,

> the preference of AWT instead of Swing might be strange for Java
> aficionados, but having the look and feel of the operating system
> (Windows, Mac, or whatever Window manager) makes life easier, not
> only for the average user but also for 'power users' who
> subconsciously recognize the buttons, highlighted input fields, etc.
> are if they have the usual appearance.
> An example of the Swing GUI that has found its way into ImageJ is
> Plugins>Utilities>Find Commands. On Windows the buttons are so dull
> that one has to look twice to recognize them as such.

The Look and Feel (LaF) in Swing is configurable and can be change by
users/developers as desired (e.g., JGoodies). Java has a number of
built-in LaF that come standard. In another Java application I work
on I have added a submenu with the selection of LAF available. Thus
it can be changed on-the-fly to the users desire.

Usually on Mac the standard Swing LaF is used as supplied by Apple (certain
tweaks are available to make the GUI look even more native that are specific to
Apple). Present day Java Swing applications on Windows look very similar
to regular applications when set correctly. On Linux, the Gtk LaF looks
like a native GNOME application, and by using the utility gtk-chtheme you can
even make a Java application look very much like a Qt/KDE application also.


> In addition, there are special and very useful operating system
> features that get lost with Swing. E.g., on the Mac one can drag and
> drop of files and folders from the "Finder" (Mac name for "File
> Manager") into open or save dialogs. Losing this would make me (and
> other Mac users) very hostile against Swing.

I do not think this is missing with Swing on OS X in the more recent Java
versions by Apple. It may have been missing a number of years back, but recent
versions on OS X have made some strides to integrate better into Aqua. I have
been following the Apple Java mailing list discussions for a few years and
many broken features have been fixed.

There is also the Quaqua library that can provide better OS X functionality
for Java applications, plus I have written some code of my own to make
a Java application communicate properly with the Aqua global menubar
(proper Quit, About handling, etc.). It can be made to work.

> On the other hand, the user does not care about the inner workings of
> ImageJ. Making things less dependent on the GUI is, in principle, a
> good idea. ImageJ has started more than 10 years ago as a small Java
> applet, probably without the expectation that it would grow so much
> and be also used differently than in interactive mode; with these
> prospects at the beginning it would probably have a different design.
> Concerning such changes at the current stage, the main problem is
> preserving compatibility with plugins - I guess that there are
> thousands of them, and many rely heavily on the internal structure.

I believe it is quite possible to change the application over from AWT
to Swing without breaking it. To do so, it would have to provide backwards
compatibility as well as a plugin interface to facilitate new Swing-based
plugins for new plugins or ports of old ones.

Better yet, a serious look at why these plugins need to rely on any GUI
related features is something I will have to find out, because the general
practice is to use what is known as a Model View Controller paradigm when
designing Java applications to keep GUI and data apart.

Once I find out the reasoning behind this then a determination can be made as
to how to proceed.

Cheers,

Raymond

[Raymond Martin-2]

Hi,

I have done a little research concerning conversion of ImageJ from AWT to
Swing, after my initial hacking of the code.

What I have found so far is that some other Java-based imaging offerings do not
actual replace AWT for the Canvas part. They actually extend it by inheriting
from Canvas. This is done in the Java Advanced Imaging (JAI) library and
JadeDisplay (High-performance Java image display component from the Jet
Propulsion Laboratory). In this way, Canvas is augmented with additional
features, better performance, etc.

Thus, Swing for the main GUI parts end up coexisting with AWT for the
image processing, display, and so forth. And plugins, as a result, will not
be broken with this type of implementation.

I will keep looking. I would not be surprised if other viable solutions exist
also.

Cheers,

Raymond

JAI: https://jai.dev.java.net/
JadeDisplay: http://www.openchannelfoundation.org/projects/jadedisplay

[Ignacio Arganda-Carreras]

Hello Raymond,

AWT-Swing coexistence is possible in the latest versions of Java, although
it has some problems on some operative systems.

If you have a look at the SIOX plugin (
http://pacific.mpi-cbg.de/wiki/index.php/SIOX) you will see an example.
Everything but the ImageWindow is a Swing component. If you try to run it in
a Linux machine, depending on the Compiz, some of the components will be
repainted correctly and some will not.

However I also think this is the best intermediate solution to start
migrating the GUI, good luck with that!!!!

ignacio

On Fri, Dec 4, 2009 at 11:00 AM, Raymond Martin <[hidden email]> wrote:

> Hi,
>
> I have done a little research concerning conversion of ImageJ from AWT to
> Swing, after my initial hacking of the code.
>
> What I have found so far is that some other Java-based imaging offerings do
> not
> actual replace AWT for the Canvas part. They actually extend it by
> inheriting
> from Canvas. This is done in the Java Advanced Imaging (JAI) library and
> JadeDisplay (High-performance Java image display component from the Jet
> Propulsion Laboratory). In this way, Canvas is augmented with additional
> features, better performance, etc.
>
> Thus, Swing for the main GUI parts end up coexisting with AWT for the
> image processing, display, and so forth. And plugins, as a result, will not
> be broken with this type of implementation.
>
> I will keep looking. I would not be surprised if other viable solutions
> exist
> also.
>
> Cheers,
>
> Raymond
>
> JAI: https://jai.dev.java.net/
> JadeDisplay: http://www.openchannelfoundation.org/projects/jadedisplay
>

--
Ignacio Arganda-Carreras, Ph.D.
Seung's lab, 46-5065
Department of Brain and Cognitive Sciences
Massachusetts Institute of Technology
43 Vassar St.
Cambridge, MA 02139
USA

Phone: [phone]
Website: http://bioweb.cnb.csic.es/~iarganda/index_EN.html

[Raymond Martin-2]

Hi Ignacio,

> AWT-Swing coexistence is possible in the latest versions of Java, although
> it has some problems on some operative systems.
>
> If you have a look at the SIOX plugin (
> http://pacific.mpi-cbg.de/wiki/index.php/SIOX) you will see an example.
> Everything but the ImageWindow is a Swing component. If you try to run it
>  in a Linux machine, depending on the Compiz, some of the components will
>  be repainted correctly and some will not.

Okay, had a look and got it to run in my ImageJ version. I am working from
the 1.43l distribution version, so it had a bug that prevented it from running
initially. That is probably due to the plugin being new. So it won't load into
older stable distributed versions I believe.

In running that plugin I have discovered a typical problem that occurs in
Java GUI applications, that of the GUI blocking during long running processes.
I have solved this in other GUI applications I work on by using a specific
threading library, Foxtrot(BSD license), that enables the use of both
synchronous and asynchronous threads in flexible ways. SwingWorker can also be
used to prevent the GUI freeze, but is not as flexible (license?).

Would adding this dependency be acceptable for the problem it solves?

Other than that, I have not run into any serious problems converting to
Swing yet. Since the potential for problems is believed to rest with
supporting plugins, would ask others to please point out, if they can, exactly
which plugins gave problems in past efforts to do what I am attempting.

Regards,

Raymond

[dscho]

Hi,

On Sat, 5 Dec 2009, Raymond Martin wrote:

> > AWT-Swing coexistence is possible in the latest versions of Java,
> > although it has some problems on some operative systems.
> >
> > If you have a look at the SIOX plugin (
> > http://pacific.mpi-cbg.de/wiki/index.php/SIOX) you will see an example.
> > Everything but the ImageWindow is a Swing component. If you try to run it
> >  in a Linux machine, depending on the Compiz, some of the components will
> >  be repainted correctly and some will not.
>
> Okay, had a look and got it to run in my ImageJ version.

Ignacio pointed to the Fiji version, which requires fiji-lib.jar.  Wayne
was not happy with that limitation and made an ImageJ >= 1.43l version.

> In running that plugin I have discovered a typical problem that occurs
> in Java GUI applications, that of the GUI blocking during long running
> processes. I have solved this in other GUI applications I work on by
> using a specific threading library, Foxtrot(BSD license), that enables
> the use of both synchronous and asynchronous threads in flexible ways.
> SwingWorker can also be used to prevent the GUI freeze, but is not as
> flexible (license?).
>
> Would adding this dependency be acceptable for the problem it solves?

We usually prefer just to use threads.

> Other than that, I have not run into any serious problems converting to
> Swing yet. Since the potential for problems is believed to rest with
> supporting plugins, would ask others to please point out, if they can,
> exactly which plugins gave problems in past efforts to do what I am
> attempting.

Maybe you can provide your version so people can actually test out?  The
most problems are actually with closed-source cannot-give-away plugins,
after all.

Ciao,
Dscho

[Raymond Martin-2]

Hi,

> > In running that plugin I have discovered a typical problem that occurs
> > in Java GUI applications, that of the GUI blocking during long running
> > processes. I have solved this in other GUI applications I work on by
> > using a specific threading library, Foxtrot(BSD license), that enables
> > the use of both synchronous and asynchronous threads in flexible ways.
> > SwingWorker can also be used to prevent the GUI freeze, but is not as
> > flexible (license?).
> >
> > Would adding this dependency be acceptable for the problem it solves?
>
> We usually prefer just to use threads.

You can, but using one of these solutions amounts to the same thing without
the work. These libraries just wrap threading code you would end up having to
write anyway, and then some. So why bother trying to manage threads when
someone else has done specific (high-quality) work to handle it properly?

> > Other than that, I have not run into any serious problems converting to
> > Swing yet. Since the potential for problems is believed to rest with
> > supporting plugins, would ask others to please point out, if they can,
> > exactly which plugins gave problems in past efforts to do what I am
> > attempting.
>
> Maybe you can provide your version so people can actually test out?  The
> most problems are actually with closed-source cannot-give-away plugins,
> after all.

Where can I post it for general access?

Regards,

Raymond