🚀 go-pugleaf

Bill:

If you use the old style awt components then, at runtime, you are connected to the
peer components of the local OS and all their warts and foibles (like windows text
widgets being limited to 32k characters when you need 32k+1).  Swing breaks the
dependency on peers and the Pluggable Look & Feel (PLAF) controls the visual
portion.

While it is not recommended (see the whitepapers on Heavyweight and Lightweight
components on the Sun site), you can mix these two together and provide an ugly and
inconsistent UI to your end users.  It's a little more headache on your side, too,
but it can be done.

-Rich

Bill Catlan wrote:

> Hello,
>
> Looking at Borland's JBuilder 3.5, I am pretty confident that I am looking at a
> Pure Java Swing interface implementation.  The pluggable look and feel is, given
> my limited understanding of AWT and Swing, a tell-tale Swing attribute.  It is
> clear to me, using the Win32 interface, that none of the Widgets inside of the
> Win32 frame are native Windows widgets.  The menus, buttons, scrollbars, while
> made to look a bit like Windows, clearly do not pick up the attributes of native
> Windows widgets (e.g., the scroll bars are narrower than the wider ones I get in
> Windows due to my customization of my scrollbar setting to make them fatter).
>
> However, playing with HotJava 3.0 for Win32 from Sun, I discovered that the
> scrollbars appear to be Windows scrollbars.  Plus, the scrollbars react to my
> mousewheel, whereas in Jbuilder 3.5, the scrollbars do not.  In HotJava, the
> menus appear to open and close as though they are native Windows menus, but the
> text font appears to be Swing or AWT style;  the menus then appear to be a sort
> of hybrid case.  Lastly, the buttons look like Swing style buttons - I think the
> look is "metal".
>
> My question, after that long introduction is this:
>
> What capabilities exist to get a Java app to look like the native platform?  The
> Jbuilder scenario is clearly mimicking the native L&F, but the HotJava scenario
> seems to tap the native API.  I imagine the HotJava scenario might introduce
> some portability issues, if it taps right into the Win32 API, but maybe not, if
> handled appopriately.
>
> What is going on with each of these interfaces?  Any thoughts appreciated.
>
> TIA,
> Bill Catlan