Separation of concerns (MVC, AWT/Swing/etc.)

[Curtis Rueden]

Hi everyone,

One goal of the ImageJDev project is to decouple the user interface from underlying data structures as completely as possible (see http://imagejdev.org/proposal, Aim IA). We want to call ImageJ image processing functionality from the command line—even headless, in situations where no graphical display is available—and from various user interfaces: in AWT, in Swing, in Android (http://developer.android.com/guide/topics/ui/), etc.

Using a compatibility layer (see http://imagejdev.org/plan, and also the "Backward compatibility" thread on the ImageJ mailing list), we can keep the vast majority of existing code functional while building a next-generation layered API using an MVC design (http://en.wikipedia.org/wiki/Model–view–controller).

Regarding concerns over switching from AWT to Swing: we will be keeping the classic ImageJ interface in AWT for maximum compatibility. However, we will also create an experimental Swing interface. I have many years of experience with Swing and am confident that Swing is reliable and portable, but we will test the interface thoroughly on various platforms. One of ImageJ's most important strengths is its cross-platform nature, and we are committed to continuing that. We may also explore other user interfaces, depending on resources (SWT, Qt, GTK+, etc.); regardless, our goal is for the architecture to allow for such interfaces to be possible with minimal effort.

The current proof-of-concept code in our Git repository (http://imagejdev.org/source-code) illustrates the IjX refactoring procedure that helped inspire the ImageJDev project, but it does not yet meet the goal of 100% compatibility. LOCI is still bringing developers on board the project, but rest assured that we will be scrutinizing the codebase next month and by spring we should have a much more concrete illustration of this design.

-Curtis

[was: Potential solution for conversion from AWT to Swing]

On Sat, Dec 5, 2009 at 10:48 AM, David Webster <dwweb...@gmail.com> wrote:

1. Why is it so important to convert from AWT to Swing?

2. Will the conversion help, hinder, or not affect users vs. developers.  If
it affects users negatively, maybe it's not worth it.

3. I've notice from these comments that Swing portability seems to be an
issue. From my experience, I find that the portabilty of ImageJ and Java is
a big plus. If you've ever tried to get openCV compile and link you know
what I mean.

4. I've had experiences with JFrames where they appear to have some
threading problems. That is sometimes they would get displayed before my
program was done add'ing components to them. This is very undesirable.

[was: ImageJX, alive, dead, or just crawling for now?]

On Mon, Dec 7, 2009 at 3:51 PM, Dimiter Prodanov <dimi...@gmail.com> wrote:

I suggest that you/we focus on the separation of the logic from the
presentation, MVC or similar.
Then capping of a Swing GUI can be relatively easy.

 

[was: ImageJX, alive, dead, or just crawling for now?]

On Tue, Dec 8, 2009 at 9:44 AM, Raymond Martin <las...@gmail.com> wrote:

On December 8, 2009 04:33:35 am Johan Henriksson wrote:
> if you absolutely want to switch GUI library, maybe you want to have a
> look one step further? there are better alternatives than swing which is
> rather buggy and does not always look native. of course, swing might
> make it easier to move from AWT.

It is the easiest step as a first effort. If the desire is to separate the GUI
from the core parts then Swing can just end up being one of a number
of potential client GUIs to the underlying functionality.