scalable layouts : Java Glossary
- scalable layouts
Java has a problem when Applets or applications are run on
very small or very big screen, or very low resolution or very high resolution
screens. The essential problem is Java is based around physical pixels. Ideally,
applications should scale to maintain an acceptable viewing size. The layouts should
rearrange and shrink, removing optional fields or labels and otherwise simplify in
low-real estate situations and expand when screen real estate is abundant.
PostScript was invented long before Java, yet
supports resolution independence with a floating point API (Application Programming Interface)
that is scaled to physical pixels. This lets you render the same image on a
640 × 479 screen or a 1024 dpi typsetter without
modification. Even it has to bow to the physical pixel reality with font rendering
hints and special rounding to pixel boundaries. At one point Java was about to adopt
Bravo PostScript rendering, then the project faded away without explanation.
What are the problem areas for autoscaling?
- Fonts. Sizes are specified in non-scaling points/pixels.
- Images. *.png, *.gif images
are specified in non-scaling pixels. *.jpg will
- The sizes of Frames, Panels etc. are specified in non-scaling pixels.
- setSize, setLocation
etc. are specified in non-scaling pixels.
- Layouts are in general not smart enough to do things like remove optional
fields, remove labelling or shorten fields when the real-estate gets tight.
- There is no general way to query the user’s visual acuity to know the
smallest point size the user can tolerate.
- There is nothing like the Microsoft dialog unit for
to use that generates auto-scaling displays.
- Knowing the width of the physical screen in pixels and the width of the
application window in pixels still gives only an approximation to the best point
size/dialog unit to use.
There are no totally satisfactory solutions,
however, there are a number of band-aids. Karsten Lentzsch of JGoodies has done most of the research and documenting
of the problem. Read his white papers and use his tools.
There are some techniques you can work with:
- Component-level scaling: use a Look & Feel like Substance or JGoodies Looks Plastic Look
& Feel family or JGoodies Looks Windows Look
& Feel that let you be very precise for the most popular resolutions
between 80dpi and 140dpi.
- Since the dialog font scales with the resolution and the desktop font setting,
if any, you may want to look for a Swing Look & Feel that honors these two
settings, e.g. Substance, Plastic and the JGoodies Windows.
- JLabel, JTextField and
JTextArea will scale correctly because they are defined
by the number of characters displayed.
- JComboBox and JList have
prototype values that are used to determine the width and height and thus will
automatically scale too.
- MigLayout and JGoodies FormLayout provide
conversions from scalable units to pixels, so you can define sizes, gaps and
borders in a resolution-independent way. You can avoid using physical pixel units
for screen positions, widths and heights.
- Microsoft Windows uses DLU (Dialog Units) for precise resolution-independence. On Windows, a
button should have a minimum width of 50 dlu. And the width of a JTree in a JScrollPane should be defined
by its content or in a resolution-independent way, often in dlu.
Oracle’s Javadoc on getScreenSize
class : available:
Oracle’s Javadoc on getScreenResolution
class : available: