[openbeos] Re: Font Sensitivity
- From: Simo Melenius <sme@xxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: 25 Jul 2002 09:06:07 +0300
John Tegen <john.tegen@xxxxxxxxxxxxxxxxxx> writes:
> $0.02:
> Integrate native font sensitivity in R2.
> Develop UI with all screen fonts set to 12pt (in the Font preferences). At
> least nothing can be bigger than this and text wont get truncated.
I've been following this list for pure interest in BeOS and OBOS, and
here are my two cents:
This is one of the fundamental no-nos in GUI design. You really
shouldn't design for any certain maximum font size and you know
that. You really shouldn't care about whether an object contains text
objects having different font sizes from 3 pixels to 4500 pixels, or
larger composite objects whose sizing constraints vary on run-time,
depending on the user's actions.
It takes two things to be font- and content-sensitive: the first is to
have one base class which knows how to distribute its child-objects on
to a line of varying length of N pixels, considering all weights,
constraints and hints presented by the child objects and its own
attributes. This base class is then derived for horizontal and
vertical container boxes. The second thing is that every object must
be able to tell its minimum and maximum dimensions so that every
parent object can tell its parent to not be sized smaller than that to
prevent content flipping under the edges of the parent box.
This is the general model of layouting boxes of visual elements, used
by Amiga's MUI (Magic User Interface) many, many, many years ago,
Unix's GTK gui-library (which sucks otherwise but the MUI-alike
abstraction level keeps me using it) and even CSS's visual box-model,
which comes mostly down to the same concept in most of its
implementations. Oh yes, also the TeX document layout engine is based
on the same concept. Let's say it's de facto way in more sophisticated
than amateur toolkits.
Not having such a thing in BeOS was one of the major itches it brought
me. AFAIK, Windows doesn't do it and AFAIK QT doesn't properly do it
(I might be wrong, I've only played with QT Designer) and I consider
every GUI-toolkit written after 1995 immature if it cannot do dynamic
layout of its objects like described above. The reasons are that it's
eventually simpler to extend such a GUI engine, it prevents visual
misfits, overfull and underfull layout, which are very important to
avoid in a graphical UI to look professional. It frees the developer
from thinking of pixels and positions and it rises the level of
abstraction high enough for the UI gadget hierarchy to be thought of
an independent, structured data structure, which just happens to get
rendered nicely on the screen media. And last but not least,
inadequate layout engine is bound to go kaboom sooner or later when
the environment the program runs in changes or advances -- or when
people just simply want to use big fonts.
best regards,
Simo Melenius
--
None of the opinions above are my employer's but mine, only mine.
Other related posts:
