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.