ImageJ Internal Frames

[James Norman]

Hello All,
I have been working with ImageJ to develop an application that displays MRI
spectroscopy data that our organization has collected/processed.  First off,
I would like to thank everyone that contributed to ImageJ, the flexibility
and ease of the code has allowed me to rapidly develop a powerful imaging
application.  One of the requirements of this project was that the Image
windows were contained within a parent frame, this was because multiple
subjects could be open, and the images needed to be grouped by the subject.
The current multiple window interface of ImageJ was not capable of doing
this.  This requirement led my down the path of using JInternalFrame objects
for the Image/Plugin windows.

I have had great success with using JInternalFrame objects and displaying
the ImageWindow/PluginFrame as internal frames contained in ImageJ.  What I
did was:

ImageWindow and PluginFrame extend JFrame.  This allowed me to add the
Container (getContentPane()) of the JFrame to the JInternalFrame.  When a
Window is opened, I take the Container of the JFrame, and add it to the
JInternalFrame.

ImageWindow and PluginFrame intercept methods such as setVisible(),
setLocation() and pack() and relay them to the JInternalFrame that the
windows content is displayed in.

WindowManagement.  Had to work with the Cascade and Tile classes to cascade
and tile appropriately.

AWT and Swing don't play nice together.  I had to change all the AWT classes
to Swing classes in the ImageCanvas, ContrastAdjuster, Threshold Adjuster
and so on.  All AWT objects that would be displayed in a JInternalFrame had
to be upgraded.  This actually was incredibly easy.  Pretty much just added
a J to everything.

Adjust for some of the small changes from an AWT Frame to a JFrame on the
Parent ImageJ window.  For instance, the default close operation on a JFrame
is to close the JFrame, and in a Frame, it is not.

So, thats how Internal Frames can be used rather than multiple windows.  My
question is, would this be useful to incorporate into ImageJ.  I would like
to have an option in ImageJ where you could toggle between the two different
interfaces (SDI and MDI its called?).  It wouldn't be difficult to relay a
setLocation() method, for instance, to either the JFrame or the
JInternalFrame depending on the type of interface the user selected.

I would be willing to contribute and test the code.  It will require a fair
amount of work to implement and document.

Let me know if this is something that the ImageJ community is interested in.

Here is a link to a print screen of the application using internal frames.
http://img264.imageshack.us/my.php?image=internalframesun9.jpg

Thanks,
James Norman

[dscho]

On Fri, 9 Feb 2007, James Norman wrote:

> AWT and Swing don't play nice together.  I had to change all the AWT
> classes to Swing classes in the ImageCanvas, ContrastAdjuster, Threshold
> Adjuster and so on.  All AWT objects that would be displayed in a
> JInternalFrame had to be upgraded.  This actually was incredibly easy.  
> Pretty much just added a J to everything.
>
> [...]
>
> My question is, would this be useful to incorporate into ImageJ.  I
> would like to have an option in ImageJ where you could toggle between
> the two different interfaces (SDI and MDI its called?).  It wouldn't be
> difficult to relay a setLocation() method, for instance, to either the
> JFrame or the JInternalFrame depending on the type of interface the user
> selected.

I do not really know how Wayne feels about switching from AWT to Swing,
but personally I feel that it might make sense to have _both_ as possible
backends. A few of my plugins depend on AWT being used...

However, since this came up last time (I was strictly negative about it
then), my opinion about this has changed. Many people seem to prefer Swing
over AWT, so I think it would be nice to have it.

Ciao,
Dscho

[James Norman]

I'm fairly new to ImageJ so I'm not privy to the history surrounding it.  An
upgrade to swing does however seem like something that will have to be done
at some point.  If the application was based on swing it would be a more
attractive platform to develop plugins on.

I have had no problem with ImageJ being based on AWT to this point.  I have
developed a plugin that uses the PluginFrame and is based on AWT.  I only
ran into some issues with ImageJ/AWT once I implemented the internal
frames.  I find the internal frames to be a very attractive feature to add
to ImageJ.  In particular, on windows it can take 4-5 clicks to make all my
images/adjusters visible, and I have to know about the Image menu to do
this.  With internal frames, it takes only one click to get back to the
images.  Also, ImageJ wouldn't be dependent on internal frames, the
interface type can be selectable.

A permanent swing branch does not sound like a good idea.  No reason to
fragment the code.  If a swing upgrade was decided upon, a temporary branch
would be necessary.  Upgrade this branch and test for a few months to
identify/fix any issues.  Also, all the plugins would need to be tested.
This branch would have all intentions of merging if the Swing upgrade was
successful.

As it stands, other then the use of internal frames, there is no real reason
to upgrade to Swing.  I think the internal frames may be a good reason to
seriously discuss an upgrade.

Can anyone provide a link to former swing upgrade discussions in the mailing
list?

Thanks,
James Norman

On 2/10/07, Johannes Schindelin <[hidden email]> wrote:

>
>
>
> On Fri, 9 Feb 2007, James Norman wrote:
>
> > AWT and Swing don't play nice together.  I had to change all the AWT
> > classes to Swing classes in the ImageCanvas, ContrastAdjuster, Threshold
> > Adjuster and so on.  All AWT objects that would be displayed in a
> > JInternalFrame had to be upgraded.  This actually was incredibly easy.
> > Pretty much just added a J to everything.
> >
> > [...]
> >
> > My question is, would this be useful to incorporate into ImageJ.  I
> > would like to have an option in ImageJ where you could toggle between
> > the two different interfaces (SDI and MDI its called?).  It wouldn't be
> > difficult to relay a setLocation() method, for instance, to either the
> > JFrame or the JInternalFrame depending on the type of interface the user
>
> > selected.
>
> I do not really know how Wayne feels about switching from AWT to Swing,
> but personally I feel that it might make sense to have _both_ as possible
> backends. A few of my plugins depend on AWT being used...
>
> However, since this came up last time (I was strictly negative about it
> then), my opinion about this has changed. Many people seem to prefer Swing
> over AWT, so I think it would be nice to have it.
>
> Ciao,
> Dscho
>
>

[Grant Harris]

Regarding MDI/SDI application design,

A while back Damien Farrell published his effort in a similar direction:
http://homepage.ntlworld.com/jfarrell/imagejmdi/

I found a  very interesting approach that generally address the SDI/MDI
conundrum here:
http://www2.sys-con.com/ITSG/virtualcd/java/archives/0901/brett/index.html
It actually allows you to switch from a JInternalFrame to a JFrame in
the same application!

A good article on mixing of so-called /heavyweight/ and /lightweight/ components is at:
http://java.sun.com/products/jfc/tsc/articles/mixing/

and the article "Understanding Containers":
http://java.sun.com/products/jfc/tsc/articles/containers/index.html

I too build applications that incorporate ImageJ, and the user interface part is problematic because of the AWT / Swing issues.  I've been thinking of ways to bridge this issue in ImageJ, but a good solution isn't clear to me yet.  It would seem that a set of 'wrappers' might work (Chris Rueden has done a couple of these in the LOCI browser).  Another approach might use interfaces; e.g. what if we had an ImageWindow interface that was implemented by ImageWindowAwt and ImageWindowSwing?  

Then there's Mistral (http://mistral.tidalwave.it/), which I think has great promise.

- Grant Harris, MBL