ImageJ as Eclipse plugin

[Marcel.]

Dear ImageJ users and developers,

at the moment i'm developping an eclipse plugin which makes use of ImageJ.
The problem is that the plugins in a self defined plugins directory don't work when i start the program programmatically.
They appear in the ImageJ-plugins-menu but won't start without getting an error-message and the cause why they can't be started.
Also when i start ImageJ programmatically the awt-frames seems to be disturbed (Gui Thread ?). So my first question is how can i archieve that ImageJ finds the ImageJ-plugins to start them properly when integrated in an eclipse-plugin ?
The second question concerns about the disturbed awt-frames(a conversion to swing works in the most parts). Is there a way to get clean awt-frames and dialogs (maybe a method to avoid the disturbance of the gui-thread)?

Thanks in advance for any answer !

[Volker Baecker]

Hello Marcelll,
I'm using swing for plugins together with an awt based ImageJ. In the
beginning the gui got messed up.
After setting lookAndFeelSet in the class Java2 to true as the first
action after ImageJ started I don't
have any problems with the gui any more.

I'm using reflection to access the private field:

            Field theField = receiver.getClass().getDeclaredField(name);
            theField.setAccessible(true);
            theField.set(receiver, value);

Cheers,
Volker
marcelll a écrit :

> Dear ImageJ users and developers,
>
> at the moment i'm developping an eclipse plugin which makes use of ImageJ.
> The problem is that the plugins in a self defined plugins directory don't
> work when i start the program programmatically.
> They appear in the ImageJ-plugins-menu but won't start without getting an
> error-message and the cause why they can't be started.
> Also when i start ImageJ programmatically the awt-frames seems to be
> disturbed (Gui Thread ?). So my first question is how can i archieve that
> ImageJ finds the ImageJ-plugins to start them properly when integrated in an
> eclipse-plugin ?
> The second question concerns about the disturbed awt-frames(a conversion to
> swing works in the most parts). Is there a way to get clean awt-frames and
> dialogs (maybe a method to avoid the disturbance of the gui-thread)?
>
> Thanks in advance for any answer !
>
>
>
>  

--
passerelle antivirus du campus CNRS de Montpellier
--

[Marcel.]

That doesn't work for me because this class switches to the windows look and feel. The problem i have is that the awt widgets are disturbed when i start them.

[dscho]

Hi,

On Tue, 4 Jul 2006, marcelll wrote:

> That doesn't work for me because this class switches to the windows look
> and feel. The problem i have is that the awt widgets are disturbed when
> i start them.

FWIW we were not able to integrate ImageJ in a Swing application, either.

Ciao,
Dscho

[Marcel.]

Hello Johannes,

i would be interested in the problems which occur in trying that.

[dscho]

Hi,

On Wed, 12 Jul 2006, marcelll wrote:

> i would be interested in the problems which occur in trying that.

[... to integrate ImageJ in a Swing application]

Our problems were that we could easily add(canvas); to a JFrame, where
canvas is an ij.gui.ImageCanvas, but it would flicker the correct image
for how long it takes to blink an eye, and then paint the background over
it. We did not have time to investigate the problem in depth, but decided
it must be something like threaded Swing vs. unthreadable AWT issue.

Hth,
Dscho

[Albert Cardona]

A comment on using the ij.gui.ImageCanvas inside a swing component: you are up
for a lot of trouble, but it's not impossible to make it work together.
TrakEM2 uses an extended ij.gui.ImageCanvas inside a JSplitPane, and the
result is very good so far. Other swing widgets are not so good at the
task -perhaps the JSplitPane is particularly suited, for it can "only"
contain one component on each side. TrakEM2's setup works fine so far in
every Sun JVM I've tried in linux, macosx and windows.

In any case a good replacement is, as long as your computer is reasonably
fast, to extend ij.gui.ImageCanvas and make the paint(Graphics g) paint to an
offscreen image, which is then painted in the paint(Graphics g) method of an
extended JPanel embedded in a JScrollPane. An alternative is to paint the
my_ImagePlus.getImage() directly, and the my_ImagePlus.getRoi().paint(g) as
well. Of course in both cases you have to reimplement the panning and
zooming -that's why I stick to the ij.gui.ImageCanvas.

Albert

--
Albert Cardona
Molecular Cell Developmental Biology
University of California Los Angeles
Tel [phone]
TrakEM2 - http://www.ini.unizh.ch/~acardona/trakem2.html
Programming: http://www.pensament.net/java/
Research: http://www.mcdb.ucla.edu/Research/Hartenstein/
Web design: http://www.pixelets.com

[Marcel.]

In your case Johannes a JPanel with the nested ImageJ-Canvas could have solved your issue. And it is never a good  idea to use paint in a JPanel instead of paintComponent(Graphics g). Then typically (adding a Canvas to JFrame or use paint instead of paintComponent....) these flickerings occur (made bad experiences too before found a good advice: http://java.sun.com/products/jfc/tsc/articles/painting/ ). But maybe you know that and the problem couldn't have solved with this procedure either.
In my case i switched everything to swt and this works excellent (for my purposes of course !) and very stable.