Posted by
simon andrews (BI) on
Dec 04, 2009; 12:12pm
URL: http://imagej.273.s1.nabble.com/ImageJ-development-involvement-contributions-tp3690030p3690076.html
On 4 Dec 2009, at 11:29, Michael Schmid wrote:
> Hi Volker, Raymond,
>
> the preference of AWT instead of Swing might be strange for Java
> aficionados, but having the look and feel of the operating system
> (Windows, Mac, or whatever Window manager) makes life easier, not
> only for the average user but also for 'power users' who
> subconsciously recognize the buttons, highlighted input fields, etc.
> are if they have the usual appearance.
You can set a global setting to give all swing objects a native system
look and feel. We've done this with our applications for ages and
virtually all of our Mac users think they're using a native Mac
application. With a command line addition you can even move the menu
bar to the top of the screen.
> In addition, there are special and very useful operating system
> features that get lost with Swing. E.g., on the Mac one can drag and
> drop of files and folders from the "Finder" (Mac name for "File
> Manager") into open or save dialogs. Losing this would make me (and
> other Mac users) very hostile against Swing.
I've just checked, and with the native look and feel set within Swing
then you can do this for JFileChooser as well. There's also nothing
stopping you from using the AWT file chooser whilst moving the main
display windows to Swing.
> On the other hand, the user does not care about the inner workings of
> ImageJ. Making things less dependent on the GUI is, in principle, a
> good idea. ImageJ has started more than 10 years ago as a small Java
> applet, probably without the expectation that it would grow so much
> and be also used differently than in interactive mode; with these
> prospects at the beginning it would probably have a different design.
> Concerning such changes at the current stage, the main problem is
> preserving compatibility with plugins - I guess that there are
> thousands of them, and many rely heavily on the internal structure.
If we're still talking about Swing vs AWT then none of the core data
structures (ImagePlus, ImageProcessor etc) need change at all. It's
only the front end which would update (ImageCanvas etc). It's
actually a really small change to convert these over to Swing since
there are Swing equivalents to all of the core AWT components. I've
made an ImagePanel derivative of ImageCanvas for some of our
applications and there are only about 10 lines of code which need to
be changed to make the switch. Remember that all swing objects
inherit from an underlying AWT object so nearly all existing method
calls will just transfer across.
I'm not saying that it's worth doing the switch between AWT and Swing,
but it's maybe not such as big switch as is being made out (and I'm
certainly not volunteering to do it :-)
TTFN
Simon.
> ________________________________________________________________
>
> On 3 Dec 2009, at 11:26, Volker Baecker wrote:
>
> (...)
>> Now what concerns swing. (...)
>> It has been discussed many times here. There is an important part
>> of the
>> ImageJ community that is absolutely hostile against swing. I
>> personally
>> don't understand why (I think these are mainly mac users and that
>> swing
>> might have caused problems in older mac versions).
>> On the other hand this is not so much of a problem since you can
>> always
>> use swing for your own plugins / or imagej based tools even if the
>> ImageJ base windows are not using it.
> (...)