🚀 go-pugleaf

"Terry Diederich" <terrydiederich@lllow.com> writes:

> It seems like Sun is positioning the Java Look and Feel (formerly called
> Metal) to be the "standard" look and feel for Java applications that will be
> cross platform.  How is it really being used?

Unless you explicitly set the L&F by involking e.g.

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

it will use the "cross-platform" L&F, which is Metal.

> Are applications using the look and feel of the platform they are running on
> (i.e. use Windows L&F if running on Windows, Motif L&F if running on Unix,
> Mac L&F if running on a Mac), or is Metal used no matter what the platform?

We use the system L&F, but mainly because we're supposed to "mirror"
an existing Win32 application written in FoxPoo.

> Is it normal to let the users decide which L&F to use through some sort of
> options or preference settings?   Is this a good idea?  Are there
> compatibility problems between one L&F and the next?

Some L&Fs can be incomplete or buggy, and largely didn't work properly
in 1.03 - you need 1.1.1 to get a reasonably stable Swing, and
e.g. the JBuilder 2 JBCL classes build on the 1.0.x naming scheme. The
2.01x patch provides alternative versions which use the 1.1.x naming.

Also, switching L&Fs can be "incomplete", depending on how your
application is managed: updateComponentTreeUI() seems to ignore
non-visible or otherwise "swapped out" components.

> I remember hearing that there was some sort of lock on the Windows L&F to
> prevent it from running on other platforms.  Sun wasn't sure they had the
> rights to distribute the L&F and Microsoft wouldn't give their approval.  Is
> this true?

Yes. However, people frequently post the common workaround: To
subclass it and have isSupportedLookAndFeel() (or whatever it's
called) return true.