Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!world!kdg
From: kdg@world.std.com (Keith D Gregory)
Newsgroups: comp.windows.x.motif
Subject: Re: Converting character-based forms
Message-ID: <1991Jun2.225525.14128@world.std.com>
Date: 2 Jun 91 22:55:25 GMT
Article-I.D.: world.1991Jun2.225525.14128
References: <1991May31.215253.3966@bellcore.bellcore.com>
Distribution: inet
Organization: The World @ Software Tool & Die
Lines: 24

In article <910601114316.2440@sony> nazgul@alfalfa.com (Kee Hinckley) writes:
>I would use the Table widget or (if you don't mind wiring the font sizes)
>a bulletin board.  Theoretically a bulletin board with the units in fontUnits
>instead of pixels would be perfect, but I'm not sure it works.

A question that has been buggong me for months (well, maybe I can say year(s)
now): "Why does the Xm100TH_FONT_UNITS unitType act the way it does?"

I don't want to say that it's brain-dead without knowing the reasons behind
its implementation, but the decision to use the font size of an arbitrary
resource -- which may bear no relation to any of the fonts actually used by
the program -- seems a bit, ah, strange.

It would seem to me that setting units in terms of the size of the font
actually used by the widget could be quite nice. Especially by an application
such as xfd (never mind that xfd already exists -- it's a good example). If
correspondance between levels of the instance tree is a concern, put fontList
into XmManager and XmPrimitive, and have children accept their parent's value
by default (maybe XmPrimitive is stretching things a bit, but XmManager fer
shure).

Comments ... please?

-kdg