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"
<G.Landini@xxxxxxxxxx>
To: <IMAGEJ@xxxxxxxxxxxx>
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
| 