ImageJ

ImageJ mdi version

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

19 messages Options

Damien Farrell

ImageJ mdi version

Hi

Anyone interested in the development of a version of ImageJ that uses a
single Swing desktop pane for all windows. Thought it might be a useful
alternative that could eventually be integrated into ImageJ proper in
some future version.
Anyone interested in this being developed further? I don't see any major
obstacles to it as yet. I made a preliminary version that seems to work
for most purposes, though many plugins will not currently work.The
ij.jar file and further info can be found at
http://homepage.ntlworld.com/jfarrell/imagejmdi/

PS. If trying this out don't overwrite your old ij.jar, make a backup
copy first.

regards

Damien Farrell

Jon Harman

Re: ImageJ mdi version

Hi,

It works pretty well for a preliminary version. I like it, but am
accustomed to the current ImageJ windows. I wonder if this could be
used to rewrite ImageJ to use Swing , but make the type of window
interface an option. Would there be any speed or memory advantages to
doing this? Would there be better tools for panning and zooming (i.e.
scrollbars) in this version? It has a better look and feel for sure.

Jon

Damien Farrell wrote:

> Hi
>
> Anyone interested in the development of a version of ImageJ that uses
> a single Swing desktop pane for all windows. Thought it might be a
> useful alternative that could eventually be integrated into ImageJ
> proper in some future version.
> Anyone interested in this being developed further? I don't see any
> major obstacles to it as yet. I made a preliminary version that seems
> to work for most purposes, though many plugins will not currently
> work.The ij.jar file and further info can be found at
> http://homepage.ntlworld.com/jfarrell/imagejmdi/
>
> PS. If trying this out don't overwrite your old ij.jar, make a backup
> copy first.
>
>
> regards
>
> Damien Farrell
>
>

Joachim Wesner

Multiple menu entry user plugins, how to do it?

Hi there,

I was wondering how some of the already "built-in" plugins get their
functionality that ONE plugin has SEVERAL menu entries, for example with
the now
permanently built-in FFT plugin, that has sub-menus like "FFT", "Inverse
FFT", "Redisplay...", FFT options..." etc.

I found out that the action for the plugin to do is controlled by the
argument in the setup routine, (easy, documented), however, what causes the
extra menu
entries and to send the extra options to setup (not so much documented
IMHO) ? Looking through the sources you can find out that it´s all in the
IJ_props.txt, which is normally AFAIK in the ij.jar file, so no "user
servicable part" while the plugin development phase.

Any idea how to implement an extra "Options/Settings" entry for a user
defined Plugin? Use 2 plugins that communicate by global variables (Brrrr)
resp.
an extra class?

Sincerely

Joachim

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Gabriel Landini

Re: ImageJ mdi version

In reply to this post by Damien Farrell

On Friday 24 March 2006 19:04, Damien Farrell wrote:
> Anyone interested in the development of a version of ImageJ that uses a
> single Swing desktop pane for all windows.

Damien,
What is the advantage of having a single pane?

My past experience with another imaging programme (the defunct Optimas) was
that only 1 pane with everything inside was a bit of a pain rather than a
plus, but there must be some advantages that I haven't thought about.

Cheers,

Gabriel

Joachim Wesner

Antwort: Re: ImageJ mdi version

Yep, I also think MDI for ImageJ would not be really useful, yet I think
having the main window come on top too, when any of its windows has the
focus
would be very useful (I remember that was already discussed some messages
ago, I also find myself often in the position: "Where the "§$$% has the
ImageJ main window gone?")

Vice versa (both of these optione could be user selectable), immediatelly
hiding all children windows when the Imagej main window becomes hidden
would be IMHO very useful too!

Joachim

Gabriel Landini
<G.Landini@BHAM. An: [hidden email]
AC.UK> Kopie: (Blindkopie: Joachim Wesner/DEWET/LMSCentral/Leica)
Gesendet von: Thema: Re: ImageJ mdi version
ImageJ Interest
Group
<[hidden email]
.GOV>

25.03.2006 11:16
Bitte antworten
an ImageJ
Interest Group

On Friday 24 March 2006 19:04, Damien Farrell wrote:
> Anyone interested in the development of a version of ImageJ that uses a
> single Swing desktop pane for all windows.

Damien,
What is the advantage of having a single pane?

My past experience with another imaging programme (the defunct Optimas) was

that only 1 pane with everything inside was a bit of a pain rather than a
plus, but there must be some advantages that I haven't thought about.

Cheers,

Gabriel

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Damien Farrell

Re: Antwort: Re: ImageJ mdi version

I think the MDI functionality is a useful option to have, but even
without that it serves as a way to see if ImageJ can converted be to use
Swing. JInternalFrames can be made JFrames with relative ease and the
MDI interface could be an option. There are still a few problems with
converting TextWindows and the Editor etc. that need to be sorted out,
but ultimately switching to Swing is a good idea, especially with the
upcoming java 6.0.

damien

Joachim Wesner wrote:

>Yep, I also think MDI for ImageJ would not be really useful, yet I think
>having the main window come on top too, when any of its windows has the
>focus
>would be very useful (I remember that was already discussed some messages
>ago, I also find myself often in the position: "Where the "§$$% has the
>ImageJ main window gone?")
>
>Vice versa (both of these optione could be user selectable), immediatelly
>hiding all children windows when the Imagej main window becomes hidden
>would be IMHO very useful too!
>
>Joachim
>
>
>
>
> Gabriel Landini
> <G.Landini@BHAM. An: [hidden email]
> AC.UK> Kopie: (Blindkopie: Joachim Wesner/DEWET/LMSCentral/Leica)
> Gesendet von: Thema: Re: ImageJ mdi version
> ImageJ Interest
> Group
> <[hidden email]
> .GOV>
>
>
> 25.03.2006 11:16
> Bitte antworten
> an ImageJ
> Interest Group
>
>
>
>
>
>On Friday 24 March 2006 19:04, Damien Farrell wrote:
>
>
>>Anyone interested in the development of a version of ImageJ that uses a
>>single Swing desktop pane for all windows.
>>
>>
>
>Damien,
>What is the advantage of having a single pane?
>
>My past experience with another imaging programme (the defunct Optimas) was
>
>that only 1 pane with everything inside was a bit of a pain rather than a
>plus, but there must be some advantages that I haven't thought about.
>
>Cheers,
>
>Gabriel
>
>
>
>______________________________________________________________________
>This email has been scanned by the MessageLabs Email Security System.
>For more information please visit http://www.messagelabs.com/email
>______________________________________________________________________
>
>
>

Wayne Rasband

Re: Multiple menu entry user plugins, how to do it?

In reply to this post by Joachim Wesner

To get a plugin to have multiple menu entries you have to package it
as a JAR file containing a plugins.config file. The example plugin at

http://rsb.info.nih.gov/ij/plugins/jar-demo.html

has 11 menu entries. Or look at the Benchmarks package at

http://rsb.info.nih.gov/ij/plugins/benchmarks.html

which consists of 6 plugins with 17 menu entries.

-wayne

On Mar 25, 2006, at 4:12 AM, Joachim Wesner wrote:

> Hi there,
>
> I was wondering how some of the already "built-in" plugins
> get their functionality that ONE plugin has SEVERAL menu
> entries, for example with the now permanently
> built-in FFT plugin, that has sub-menus like
> "FFT", "Inverse FFT", "Redisplay...", FFT options..." etc.
>
> I found out that the action for the plugin to do is controlled
> by the argument in the setup routine, (easy, documented),
> however, what causes the extra menu entries and to send
> the extra options to setup (not so much documented IMHO) ?
> Looking through the sources you can find out that it´s all in
> the IJ_props.txt, which is normally AFAIK in the ij.jar file, so
> no "user servicable part" while the plugin development phase.
>
> Any idea how to implement an extra "Options/Settings" entry
> for a user defined Plugin? Use 2 plugins that communicate
> by global variables (Brrrr) resp. an extra class?
>
> Sincerely
>
> Joachim
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

Wayne Rasband

Re: Antwort: Re: ImageJ mdi version

In reply to this post by Joachim Wesner

> Yep, I also think MDI for ImageJ would not be really useful,
> yet I think having the main window come on top too, when
> any of its windows has the focus would be very useful
> (I remember that was already discussed some messages
> ago, I also find myself often in the position: "Where the
> "§$$% has the ImageJ main window gone?")

You can bring the main ImageJ window to the top by pressing return
(or enter) when any ImageJ window has focus. The enter key is the
keyboard shortcut for the Window>'ImageJ [enter]' command.

-wayne

Robert Baer

Re: ImageJ mdi version

In reply to this post by Gabriel Landini

Very interesting Damien. I enjoyed looking at it will probably play a
little more.

First as to MDI. I expect the advantages of MDI are in the eye of the
beholder which, in turn, depends on many historical things that differ for
each of us. I am mainly a Windows user and more of my applications use the
MDI than SDI approach so I tend to feel more comfortable with MDI. Jochim
hit upon the 'where is the main menu' thing which is always a little more
certain in a parent-frame world, but just as quickly Wayne reminded us that
the facile SDI user will use <ENTER> to bring the window to the top. (Thanks
for that Wayne). The other thing that sometime frustrates me is the
overpopulation of my task bar with a vast number of 'Image' buttons that are
all subpieces of a single ImageJ project. With Windows XP these eventually
get collected together and grouped (which helps), but I number this
'subtask' invasion of the task bar among the downsides of SDI applications.

For Daminen's 'proof of concept project' he has built an MDI, but he has not
added all of the functionality that one generally finds in such an
application structure. Generally an MDI app is more integrated than a SDI
dumped into a single parent frame. Let me share one example of an MDI
functionality that I use in the Photoshop MDI, and that I sometimes miss in
ImageJ. The context is working with multiple images from multiple treatment
conditions during an experiment. When doing the equivalent of Window | Tile
the Photoshop MDI parent window only tiles those images that are not
minimized. This is a quick and flexible way to make montage like layouts in
the MDI parent frame. The parent window can itself be sized such that I can
look at data in an Excel spreadsheet while contemplating the images. The
parent frame itself is the flexible office space that I work in. The MDI
design encapsulated one philosophy of how to best facilite the work flow.
The SDI supporter will rightfully come back by pointing out that it is far
easier to drag some of the images to monitor 2 in a dual monitor workstation
with an SDI interface. Again the SDI embeds a philosophy of how workflow is
most easily mangaed. Which interface is BETTER is not an answerable
question. In the end, it boils down to the job to be accomplished, the OS
preference and experience of the user, and the creativity and foresight of
the SDI or MDI developer.

I had not heard of 'Swing' before, but the link (
http://java.sun.com/products/jfc/tsc/articles/mixing/ ) that you provide on
your download page seems to suggest that Swing components are light-weight
Java objects that are being positioned as an alternative to AWT components.
I am certain there are trade-offs, but I don't know what they are. For
example, it appears that Swing components have a single thread rule. Would
this have implications for ImagJ? I could not tell if Swing would be an
integrated part of the next JDK or not.

Rob
----- Original Message -----
From: "Gabriel Landini" <[hidden email]>
To: <[hidden email]>
Sent: Saturday, March 25, 2006 4:16 AMs
Subject: Re: ImageJ mdi version

> On Friday 24 March 2006 19:04, Damien Farrell wrote:
>> Anyone interested in the development of a version of ImageJ that uses a
>> single Swing desktop pane for all windows.
>
> Damien,
> What is the advantage of having a single pane?
>
> My past experience with another imaging programme (the defunct Optimas)
> was
> that only 1 pane with everything inside was a bit of a pain rather than a
> plus, but there must be some advantages that I haven't thought about.
>
> Cheers,
>
> Gabriel
>

Duane and Julie

Re: ImageJ mdi version

Some little notes about my experience on Mac OSX:

OS X (and probably Linux as well) doesn't suffer from the
overpopulation of a task bar.

I frequently have many large images open, often more than will fit on
my screen (and I have a 30" cinema display). If the interface became
MDI, that would actually reduce my display area, making it all that
more cramped. If I ran the MDI full screen, then I'm actually back
to SDI with the edges removed. No gain and a little loss.

Just so you know, Photoshop on Mac is SDI (at least it is for me).
XCode (Mac IDE) is either, depending on the user preference. Eclipse
is MDI. For some reason I seem to prefer MDI for development and SDI
for graphics and imaging. Go figure.

For those of you who are Windoze users and don't know, on a Mac the
menu bar is not attached to each window: it is at the top of the
screen, and is always in the same place. This kind of makes it
always MDI even if it's SDI. Sort of. Perhaps that's full screen
MDI with a transparent background? :-)

I guess the bottom line is: please don't mess with an interface
without taking into account other operating systems and user
preferences. I mentioned XCode above because it did that precisely:
you can have it either way, and in fact it allows you to have it both
ways to some extent. Yes, the first reply will say that we can just
have two different ImageJs, but a branch in the code is just a
really, really bad idea. I like the interface just the way it is.

Cheers!

duane

On Mar 25, 2006, at 8:45 AM, Robert W. Baer, Ph.D. wrote:

> Very interesting Damien. I enjoyed looking at it will probably
> play a little more.
>
> First as to MDI. I expect the advantages of MDI are in the eye of
> the beholder which, in turn, depends on many historical things that
> differ for each of us. I am mainly a Windows user and more of my
> applications use the MDI than SDI approach so I tend to feel more
> comfortable with MDI. Jochim hit upon the 'where is the main
> menu' thing which is always a little more certain in a parent-frame
> world, but just as quickly Wayne reminded us that the facile SDI
> user will use <ENTER> to bring the window to the top. (Thanks for
> that Wayne). The other thing that sometime frustrates me is the
> overpopulation of my task bar with a vast number of 'Image' buttons
> that are all subpieces of a single ImageJ project. With Windows XP
> these eventually get collected together and grouped (which helps),
> but I number this 'subtask' invasion of the task bar among the
> downsides of SDI applications.
>
> For Daminen's 'proof of concept project' he has built an MDI, but
> he has not added all of the functionality that one generally finds
> in such an application structure. Generally an MDI app is more
> integrated than a SDI dumped into a single parent frame. Let me
> share one example of an MDI functionality that I use in the
> Photoshop MDI, and that I sometimes miss in ImageJ. The context is
> working with multiple images from multiple treatment conditions
> during an experiment. When doing the equivalent of Window | Tile
> the Photoshop MDI parent window only tiles those images that are
> not minimized. This is a quick and flexible way to make montage
> like layouts in the MDI parent frame. The parent window can itself
> be sized such that I can look at data in an Excel spreadsheet while
> contemplating the images. The parent frame itself is the flexible
> office space that I work in. The MDI design encapsulated one
> philosophy of how to best facilite the work flow. The SDI supporter
> will rightfully come back by pointing out that it is far easier to
> drag some of the images to monitor 2 in a dual monitor workstation
> with an SDI interface. Again the SDI embeds a philosophy of how
> workflow is most easily mangaed. Which interface is BETTER is not
> an answerable question. In the end, it boils down to the job to be
> accomplished, the OS preference and experience of the user, and the
> creativity and foresight of the SDI or MDI developer.
>
> I had not heard of 'Swing' before, but the link ( http://
> java.sun.com/products/jfc/tsc/articles/mixing/ ) that you provide
> on your download page seems to suggest that Swing components are
> light-weight Java objects that are being positioned as an
> alternative to AWT components. I am certain there are trade-offs,
> but I don't know what they are. For example, it appears that Swing
> components have a single thread rule. Would this have implications
> for ImagJ? I could not tell if Swing would be an integrated part
> of the next JDK or not.
>
> Rob
> ----- Original Message ----- From: "Gabriel Landini"
> <[hidden email]>
> To: <[hidden email]>
> Sent: Saturday, March 25, 2006 4:16 AMs
> Subject: Re: ImageJ mdi version
>
>
>> On Friday 24 March 2006 19:04, Damien Farrell wrote:
>>> Anyone interested in the development of a version of ImageJ that
>>> uses a
>>> single Swing desktop pane for all windows.
>>
>> Damien,
>> What is the advantage of having a single pane?
>>
>> My past experience with another imaging programme (the defunct
>> Optimas) was
>> that only 1 pane with everything inside was a bit of a pain rather
>> than a
>> plus, but there must be some advantages that I haven't thought about.
>>
>> Cheers,
>>
>> Gabriel

Robert Baer

Opening multiple images simultaneously

In previous versions (at least through 1.34) one had the option of opening
multiple images at once by usinging SHIFT to select sequential images or
CTRL to select arbitrary collections. This was presumably implemented
through JFileOpener and could be turned on with the Edit | Options | Misc...
menu and checking Open/Save Using JFileChooser.

This choice seems to be gone in 1.37a or 1.37b. Further the default Open
behavior does not seem to support the use of SHFT and CTRL to do multiple
image opens. Is there a way to restore this functionality?

Thanks,
Rob

Robert Baer

Re: Opening multiple images simultaneously

Looks like I had it a little wrong about the loss of file opening
functionality. For what it's worth the machines in question are either
Windows XP or Windows 2000.

I now find that I have one machine with ImageJ 1.37a that HAS SHFT and CTRL
functionality although it does not any longer have have a JFileChooser
selection box in the Misc... menu. The difference is that this machine is
running JRE 1.5.0_03. All the machines with loss of functionality have JRE
1.5.0_06.

Is rolling back the JRE (if it works) the only solution to restoring
functionality?

Thanks,
Rob

----- Original Message -----
From: "Robert W. Baer, Ph.D." <[hidden email]>
To: <[hidden email]>
Sent: Sunday, March 26, 2006 6:17 PM
Subject: Opening multiple images simultaneously

> In previous versions (at least through 1.34) one had the option of opening
> multiple images at once by usinging SHIFT to select sequential images or
> CTRL to select arbitrary collections. This was presumably implemented
> through JFileOpener and could be turned on with the Edit | Options |
> Misc... menu and checking Open/Save Using JFileChooser.
>
> This choice seems to be gone in 1.37a or 1.37b. Further the default Open
> behavior does not seem to support the use of SHFT and CTRL to do multiple
> image opens. Is there a way to restore this functionality?
>
> Thanks,
> Rob

Tony Collins-2

Re: ImageJ mdi version

In reply to this post by Damien Farrell

Damien,

Nice work. It must have been quite an investment of your time.

I wonder if people will be split along OS lines for this one. Generally,
Windows users would probably prefer this look and feel. In fact I know
for a fact that some Windows users are put off ImageJ by the look and
feel. They're a little suspicious that they can see the desktop and the
fact that ImageJ does not look like their other applications.

In fact, I've found that recent attempts by microscoft for a
multi-document interface with their windows office applications
generally get turned back to a SDI off in the options settings!

Personally, I'd like to see the single pane approach, maybe because I
use ImageJ alongside many other apps and switching between them can
involde a bit of hunting around. I can see that many users would not
want a change though. Could we follow Microsoft's shining example (can't
say that very often!) and have this as an option?

Tony

Damien Farrell wrote:

> Hi
>
> Anyone interested in the development of a version of ImageJ that uses a
> single Swing desktop pane for all windows. Thought it might be a useful
> alternative that could eventually be integrated into ImageJ proper in
> some future version.
> Anyone interested in this being developed further? I don't see any major
> obstacles to it as yet. I made a preliminary version that seems to work
> for most purposes, though many plugins will not currently work.The
> ij.jar file and further info can be found at
> http://homepage.ntlworld.com/jfarrell/imagejmdi/
>
> PS. If trying this out don't overwrite your old ij.jar, make a backup
> copy first.
>
>
> regards
>
> Damien Farrell
>
>

--
Tony Collins, Ph.D.
Facility Manager
Wright Cell Imaging Facility
Toronto Western Research Institute
13-407 McLaughlin Pavilion
399 Bathurst Street
Toronto, ON. M5T 2S8
tel. (416) 603 5367 fax: (416) 603 5745
http://www.uhnresearch.ca/wcif

Roland Talanow, MD. PhD.

Re: ImageJ mdi version

Dear ImageJ users,
I can understand both sides (me - I personally prefer the SDI).
Question to all developers, especially to Wayne:
Can't we just implement an option (e.g. in the config file) to allow the user to
chose how (SDI versus MDI) ImageJ should be opened?

This would satisfy everybody's needs.
Thank you,
Roland

Roland Talanow, MD, PhD
Department of Radiology
The Cleveland Clinic Foundation
[hidden email]

Zitat von Tony Collins <[hidden email]>:

> Damien,
>
> Nice work. It must have been quite an investment of your time.
>
> I wonder if people will be split along OS lines for this one. Generally,
> Windows users would probably prefer this look and feel. In fact I know
> for a fact that some Windows users are put off ImageJ by the look and
> feel. They're a little suspicious that they can see the desktop and the
> fact that ImageJ does not look like their other applications.
>
> In fact, I've found that recent attempts by microscoft for a
> multi-document interface with their windows office applications
> generally get turned back to a SDI off in the options settings!
>
> Personally, I'd like to see the single pane approach, maybe because I
> use ImageJ alongside many other apps and switching between them can
> involde a bit of hunting around. I can see that many users would not
> want a change though. Could we follow Microsoft's shining example (can't
> say that very often!) and have this as an option?
>
> Tony
>
>
> Damien Farrell wrote:
> > Hi
> >
> > Anyone interested in the development of a version of ImageJ that uses a
> > single Swing desktop pane for all windows. Thought it might be a useful
> > alternative that could eventually be integrated into ImageJ proper in
> > some future version.
> > Anyone interested in this being developed further? I don't see any major
> > obstacles to it as yet. I made a preliminary version that seems to work
> > for most purposes, though many plugins will not currently work.The
> > ij.jar file and further info can be found at
> > http://homepage.ntlworld.com/jfarrell/imagejmdi/
> >
> > PS. If trying this out don't overwrite your old ij.jar, make a backup
> > copy first.
> >
> >
> > regards
> >
> > Damien Farrell
> >
> >
>
> --
> Tony Collins, Ph.D.
> Facility Manager
> Wright Cell Imaging Facility
> Toronto Western Research Institute
> 13-407 McLaughlin Pavilion
> 399 Bathurst Street
> Toronto, ON. M5T 2S8
> tel. (416) 603 5367 fax: (416) 603 5745
> http://www.uhnresearch.ca/wcif
>

Wayne Rasband

Re: Opening multiple images simultaneously

In reply to this post by Robert Baer

> In previous versions (at least through 1.34) one had the option of
> opening multiple images at once by usinging SHIFT to select sequential
> images or CTRL to select arbitrary collections. This was presumably
> implemented through JFileOpener and could be turned on with the Edit |
> Options | Misc... menu and checking Open/Save Using JFileChooser.

The "Open/Save Using JFileChooser" option was renamed "Use JFileChooser
to Open/Save" and moved to the Edit>Options>Input/Output dialog box.

-wayne

Bob Curley

Re: ImageJ mdi version

In reply to this post by Damien Farrell

I have also made some changes to ImageJ to allow a single pane for all
windows, although I used a tabbed pane instead of MDI. Also, I tried to
minimally change the base ImageJ classes such that the jdk 1.1 AWT UI
still works.

Key changes I made to ImageJ:
* Add/Use IJ.getAppFrame() instead of IJ.getInstance() as the frame
showing isn't the ImageJ instance for Swing (it's a JFrame).
* A few changes to Toolbar,ImageWindow,ImageCanvas,ImageJ to use another
UI framework for display (don't show the AWT UI).
* Menus -- static methods need to be wrapped to call the singleton Menus
instance (which may be a derived class, i.e. another UI framework).

I'm not sure what the interest might be, but you can have a look (applet
links) at
http://home.blarg.net/~bobcat/ImageJ/index.html

Note I used the swixml XUL engine to create much of the Swing UI (e.g.
menus, toolbar), meaning you could create your own customized UI by
using a different XML file.

If there is interest in making the core ImageJ changes I could merge in
the latest ImageJ version and provide my changes to Wayne.

Thanks,
Bob Curley

Damien Farrell wrote:

Klughammer GmbH

Re: ImageJ mdi version

Dear Bob,

your Swing UI looks good. I'd like to use it.

Anneliese

Bob Curley schrieb:

> I have also made some changes to ImageJ to allow a single pane for all
> windows, although I used a tabbed pane instead of MDI. Also, I tried
> to minimally change the base ImageJ classes such that the jdk 1.1 AWT
> UI still works.
> Key changes I made to ImageJ:
> * Add/Use IJ.getAppFrame() instead of IJ.getInstance() as the frame
> showing isn't the ImageJ instance for Swing (it's a JFrame).
> * A few changes to Toolbar,ImageWindow,ImageCanvas,ImageJ to use
> another UI framework for display (don't show the AWT UI).
> * Menus -- static methods need to be wrapped to call the singleton
> Menus instance (which may be a derived class, i.e. another UI framework).
>
> I'm not sure what the interest might be, but you can have a look
> (applet links) at
> http://home.blarg.net/~bobcat/ImageJ/index.html
>
> Note I used the swixml XUL engine to create much of the Swing UI (e.g.
> menus, toolbar), meaning you could create your own customized UI by
> using a different XML file.
>
> If there is interest in making the core ImageJ changes I could merge
> in the latest ImageJ version and provide my changes to Wayne.
>
> Thanks,
> Bob Curley
>
> Damien Farrell wrote:
>
>> Hi
>>
>> Anyone interested in the development of a version of ImageJ that uses
>> a single Swing desktop pane for all windows. Thought it might be a
>> useful alternative that could eventually be integrated into ImageJ
>> proper in some future version.
>> Anyone interested in this being developed further? I don't see any
>> major obstacles to it as yet. I made a preliminary version that seems
>> to work for most purposes, though many plugins will not currently
>> work.The ij.jar file and further info can be found at
>> http://homepage.ntlworld.com/jfarrell/imagejmdi/
>>
>> PS. If trying this out don't overwrite your old ij.jar, make a backup
>> copy first.
>>
>>
>> regards
>>
>> Damien Farrell
>>
>>
>
>

Damien Farrell

Re: ImageJ mdi version

In reply to this post by Bob Curley

I think from the previous comments that there is minimal interest in an
MDI version, especially for Mac users of this app. However I do think
that the swing UI would be a valuable future feature of the core version
of ImageJ and Bob's solution seems a pretty good one. I don't like the
tabbed panes version myself, but as he said, it provides the flexibility
needed to allow users to customize their user interface.

Damien

Bob Curley wrote:

Jon Harman

Re: ImageJ mdi version

Hi,

The feature here that makes it worthwhile for me is the zoom with
scrollbars. I love that, although I notice that it isn't an
interpolated zoom, too bad.

Jon
Damien Farrell wrote:

> I think from the previous comments that there is minimal interest in
> an MDI version, especially for Mac users of this app. However I do
> think that the swing UI would be a valuable future feature of the core
> version of ImageJ and Bob's solution seems a pretty good one. I don't
> like the tabbed panes version myself, but as he said, it provides the
> flexibility needed to allow users to customize their user interface.
>
> Damien
>
> Bob Curley wrote:
>
>> I have also made some changes to ImageJ to allow a single pane for
>> all windows, although I used a tabbed pane instead of MDI. Also, I
>> tried to minimally change the base ImageJ classes such that the jdk
>> 1.1 AWT UI still works.
>> Key changes I made to ImageJ:
>> * Add/Use IJ.getAppFrame() instead of IJ.getInstance() as the frame
>> showing isn't the ImageJ instance for Swing (it's a JFrame).
>> * A few changes to Toolbar,ImageWindow,ImageCanvas,ImageJ to use
>> another UI framework for display (don't show the AWT UI).
>> * Menus -- static methods need to be wrapped to call the singleton
>> Menus instance (which may be a derived class, i.e. another UI
>> framework).
>>
>> I'm not sure what the interest might be, but you can have a look
>> (applet links) at
>> http://home.blarg.net/~bobcat/ImageJ/index.html
>>
>> Note I used the swixml XUL engine to create much of the Swing UI
>> (e.g. menus, toolbar), meaning you could create your own customized
>> UI by using a different XML file.
>>
>> If there is interest in making the core ImageJ changes I could merge
>> in the latest ImageJ version and provide my changes to Wayne.
>>
>> Thanks,
>> Bob Curley
>>
>> Damien Farrell wrote:
>>
>>> Hi
>>>
>>> Anyone interested in the development of a version of ImageJ that
>>> uses a single Swing desktop pane for all windows. Thought it might
>>> be a useful alternative that could eventually be integrated into
>>> ImageJ proper in some future version.
>>> Anyone interested in this being developed further? I don't see any
>>> major obstacles to it as yet. I made a preliminary version that
>>> seems to work for most purposes, though many plugins will not
>>> currently work.The ij.jar file and further info can be found at
>>> http://homepage.ntlworld.com/jfarrell/imagejmdi/
>>>
>>> PS. If trying this out don't overwrite your old ij.jar, make a
>>> backup copy first.
>>>
>>>
>>> regards
>>>
>>> Damien Farrell
>>>
>>>
>>
>>
>