gdykes@batcomputer.tn.cornell.edu (Gene Dykes) (04/28/89)
The Xcu widget set is being posted to comp.sources.x. I have tested it
on an HP, a Sun 3, and an IBM RT. I have reports that it works okay on
a few other machines, so there shouldn't be too many system-dependent
problems.
Xcu contains numerous widgets designed specifically for the task of
generating nice looking menus. A brief synopsis appears at the end
of this article.
Although it is pretty solid, I am sure I can count on many of you to use my
widgets in circumstances which I would never have dreamed of. So...
Please send comments, gripes, wishlists, etc. to me, and I will see what
I can do to set things right. In particular, please let me know in what
way my documentation didn't clue you in on what you needed to know.
Those who got a sneak preview had nice things to say about Xcu, but there
were also a couple minor problems reported, so here is a very short list
of known bugs not mentioned in the manuals:
1) During "make", the very last thing it tries to do is wrong. You may
safely ignore this error, if it has to do with making "long".
(Can't make long.o because long.c is not there.)
2) When labels are shrunk below their desired size, the shadows or
picture frames are shrunk before clipping of the text occurs. This
is good. What is wrong is that if the labels are resized larger again,
the shadows or picture frames don't return.
3) One person has reported a "flicker" problem with my labels,
either because of a slow machine, or because of the geometry manager
used. I am investigating this. It's possible that refreshing is so
efficient on most machines that if there is an error in the way that
I repaint labels, it is not objectionable. Please let me know the
circumstances if you notice this happening.
4) I have had intermittent problems when I attempt to change the size or
color of borders. I suspect an intrinsics bug, but I suppose there
is the possibility that it is something I'm doing wrong.
After a week or so of attending to fixes such as these, I'll put this
stuff on expo.
Now, for a short trip up onto my soapbox. I recently posted an article
suggesting some conventions for folks writing widget sets like Xcu. Since
there were no followups or replies, I don't know if everybody agrees,
disagrees, or doesn't care. But without some conventions like I suggested,
those of you who try out my CuWlm layout widget and love it will soon find
out why my proposal is important. In Xcu there is a shell script called
"wlm_incl_make", which can make a certain required include file automatically,
but only if all widgets follow the same conventions. E.g., if one has a
widget class "Bar" in the widget set "Foo", then the public include file
can be found as:
#include <Foo/Bar.h>
Currently, taking Xcu, Xaw, Xsw, and Xhp as examples, there are already
four different ways of deriving the name and location of the include file.
Such lack of uniformity means that you, the programmers will have to hand
craft this include file when my script fails to create a good one. It
isn't hard at all, but it's an unnecessary nuisance. Off the soapbox...
Brief synopsis of the contents of Xcu, followed by a bit of the history
and philosophy of it:
Two Geometry Manager Widgets :
Tbl : Layout according to "tbl" formats (the troff preprocessor).
Just the thing for laying out a fixed number of widgets in a
rectangular area. Simple row/column matrices are a small subset
of its capabilities. Handles resizes elegantly.
Deck : Maintain widgets one on top of the other, so that they are all the
same size and only one is visible at a time. Useful for "pages"
of a menu.
A rework of the Xaw Simple/Label/Command widgets :
Simple : Puts very nice looking picture frames around or shadows behind
widgets subclassed from it.
Label : Permits multiple lines of text.
Has a "biggestLabel" resource that lets it be initially sized
large enough to encompass any reasonable text changes without
annoying resizes.
Command : No new features -- just rederived from the above.
A button manager widget :
Bmgr : This button manager divorces layout semantics from the button
semantics. It is not a geometry manager. Button widgets are
registered with it via public routines. This is a big win when
the buttons must be spread out among a variety of geometry
managers, or, conversely, there must be a number of different
kinds of buttons under the layout control of a single geometry
manager. It understands single and double button toggles,
one of many, any of many, etc.
Button : Similar to the Command widget, but it is tailored for use with
the Bmgr widget. The primary difference is that it relies on
the Bmgr widget to inform it of its state.
And last, but definitely not least (more than 5500 lines of source code) :
Wlm : a widget that builds a widget tree from a layout description language,
and mediates many of the widget/client communications. Once you get
used to it you'll never want to live without it. Menus can be
designed, tested, and modified without writing a single line
of client code. The description language has notations for inter-
widget communications that permit complex menu semantics to be
implemented completely outside of the client.
For those who care, here is a bit of the history and philosophy behind the
Xcu widget set. Part of my job is to help scientific programmers write
interactive graphics applications. It has been observed that a lot,
if not most, of the programming time for such applications is spent
creating menu interfaces as opposed to concentrating on the science
involved. This widget set was designed with the goal of greatly reducing
the time involved in menu creation, while making it easy to specify
reasonably complex and aesthetically pleasing menus.
Xcu contains a bunch of general purpose widgets that serve most of my needs
for creating button oriented menus. Rather than creating a row widget and
a column widget and a row/column widget and lots of special layouts, I
decided that one geometry manager based on the "tbl" language would provide
almost all the functionality I'd ever need. Rather than making a radiobutton
widget and a checkbox widget, and..., I created one button manager widget that
manages the semantics but leaves the layout to a separate geometry manager,
usually, CuTbl. Now, I have no delusions that this should replace all
existing button selection widgets, but it fills a nice niche.
There are at least two basic approaches to creating a higher than
toolkit-level menu description. One is by using a descriptive grammar.
The other is by direct graphical manipulation. After a demo of my CuWlm
widget, I am invariably asked why I don't have a direct graphical manipulation
interface. My answer is that I would like to have one, but that I also
think a well-defined grammar should exist beneath it. Without it, menus
would tend to be free-form, and it would be next to impossible to write
extensible tools to go along with it. (I also happen to LIKE grammars :-))
So, the reason I don't have direct graphical manipulation is because that
is what's coming next... That is, it's coming if I can convince my boss
it's the right thing to do. Feel free to mail me your comments on this.
--
Gene Dykes, gdykes@tcgould.tn.cornell.edu