Java claims WORA

[John B. Matthews]

one of the big problems is when you substitute a font, the characters
are not the same size. I would like to normalize fonts to their true
size so that when you substitute fonts, the actual real estate
consumed varies only a little.

I must demur: a typical JComponent, such as JLabel, goes to considerable
lengths to calculate its preferred size using the metrics of the
selected Font. As long as you

- don't veto the calculation,
- don't preclude resizing,
- do use a LayoutManager, and
- do pack() the enclosing Container

the chosen Font is irrelevant. If the Font must be changed dynamically,
revalidate() and repaint() should suffice.

Another would be a guaranteed to render all glyphs, even if it means
substituting from some other font. Failing that at telling the
truth. Java claims to render a glyph when all it does in render some
generic glyph.

Font substitution shouldn't cause a problem. Missing glyphs and
mendacious canDisplay() are annoying, but the metrics are typically
reliable.

 

[Mike Schilling]

It is spelled "Java".

I am not aware of a Java port to the PDP-8.

I don't see why not. A 12-bit address space would make writing a garbage
collector a snap.

 

[Mike Schilling]

That is supposed to be the reason why VAX did not get Java.

But they could have emulated IEEE FP if they wanted to.

They had 4 different floating point formats, what's one more?

 

[Lew]

I must demur: a typical JComponent, such as JLabel, goes to considerable
lengths to calculate its preferred size using the metrics of the
selected Font. As long as you

- don't veto the calculation,
- don't preclude resizing,
- do use a LayoutManager, and
- do pack() the enclosing Container

the chosen Font is irrelevant. If the Font must be changed dynamically,
revalidate() and repaint() should suffice.


Font substitution shouldn't cause a problem. Missing glyphs and
mendacious canDisplay() are annoying, but the metrics are typically
reliable.

Depends on what problem you care about, and what constitutes relevance.

You might not be happy with a screen that doubles its width to accommodate a
font, for design reasons.

Sure, Swing handles the technical details of resizing, and layouts do wonders
to work around variances in fonts and so forth, but that's all technical
problems and solutions and relevance.

Design problems and solutions and relevance revolve around what looks right
and works for the program's purpose, i.e., the user's purpose. Roedy's wish
for fonts that squish instead of windows that widen is not uncommon nor
unreasonable, from a design perspective. You might prefer the data entry box
not get smaller to make room for a longer prompt.

So technical dimension, no problem, design dimension, eh, depends on the
design and what changes it can withstand.

 

[David Lamb]

An Architecture that works for both Swing (or SWT) and Android
would look as follows:

+---------------+
+ Swing GUI |
+---------------+-+---------------+
| Headless Part |
+---------------+-+---------------+
| Android GUI |
+---------------+

I was hoping to develop some notes for doing that to pass along to
upper-year undegrads. Do you have any suggestions / guidelines /
tutorials you could point to?

 

[Jan Burse]

I was hoping to develop some notes for doing that to pass along to
upper-year undegrads. Do you have any suggestions / guidelines /
tutorials you could point to?

If you can place business delegates into the headless part,
then you are practically done. You only need two different
clients, a Swing client and an Android client.

http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html

The above would allow to build a Swing client and an Android
client that differ considerably, for example that implement
different workflow and/or different GUI layout.

If you want some common support so that a certain similarity
of the Swing client and the Android is assured, you might want to
look into the MVC pattern for example.

http://java.sun.com/blueprints/patterns/MVC-detailed.html

The result would then be something else:

+---------------+
+ Swing View |
+---------------+-+----------------+ +---------------+
| GUI Controller |-| Headless Part |
+---------------+-+----------------+ +---------------+
| Android View |
+---------------+

But I didn't follow the above architecture, since I was expecting
to implement a different layout and/or workflow for the Android
client, compared to the Swing client that was already there.

But manually programmatically by mirroring Swing code in the
Android code in many places I have now a similar layout and/or
workflow. But it is not enforced and changing the layout and/or
workflow accross both clients is now a double effort.

Bye

 

[Jan Burse]

http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html


The above would allow to build a Swing client and an Android
client that differ considerably, for example that implement
different workflow and/or different GUI layout.

Oops, I just see the above pattern is a little bit over
the top, it more addresses lose coupling of client and
business services. But I guess it is not forbidden to also
tightly couple them. You still get the reuse benefit.

In my present case the client and the business services
form one tier. A business servivce might spawn to other
tiers. But client and business services are bundled
together for deloyment.

Practically one can approach this as follows:

Create Project I for the Business Services,
-------------------------------------------
you can compile the result into business.jar

Create Project II for the Swing Client,
-------------------------------------------
this project will use the library business.jar,
and produce swingclient.jar. To execute the
result both business.jar and swingclient.jar
will be in the class path. But you can also
merge them.

Create Project III for the Android Client,
-------------------------------------------
same idea as for the Swing Client, but you
need to additionally run your results to
some Android tool chains. And have some
Android emulator and/or device available
for testing.

Have fun

Bye

 

[John B. Matthews]

I must demur: a typical JComponent, such as JLabel, goes to
considerable lengths to calculate its preferred size using the
metrics of the selected Font. As long as you

- don't veto the calculation,
- don't preclude resizing,
- do use a LayoutManager, and
- do pack() the enclosing Container

the chosen Font is irrelevant. If the Font must be changed dynamically,
revalidate() and repaint() should suffice.


Font substitution shouldn't cause a problem. Missing glyphs and
mendacious canDisplay() are annoying, but the metrics are typically
reliable.

Depends on what problem you care about, and what constitutes relevance.

You might not be happy with a screen that doubles its width to
accommodate a font, for design reasons.

Sure, Swing handles the technical details of resizing, and layouts do
wonders to work around variances in fonts and so forth, but that's
all technical problems and solutions and relevance.

Design problems and solutions and relevance revolve around what looks
right and works for the program's purpose, i.e., the user's purpose.
Roedy's wish for fonts that squish instead of windows that widen is
not uncommon nor unreasonable, from a design perspective. You might
prefer the data entry box not get smaller to make room for a longer
prompt.

So technical dimension, no problem, design dimension, eh, depends on
the design and what changes it can withstand.[/QUOTE]

This is a valuable distinction. The physical font selected for a given
family may not _double_ the width, but localization might come close. As
a practical matter, I sometimes relegate the full text to a tool tip,
leaving a digest in the label. Size variants can be handy, too:

<http://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/size.html>