August 21, 1990

Color/B&W support
    We need to solve color vs. black&white applications.  Right now, things
    tend to work well on one or the other, but not really on both.  One
    option, the one imposed by Open-Look, is to have two different looks
    for monochrome and color.  In any case, we need to make a pass through
    the widgets and change the repaint procedure to make a runtime
    determination of how to repaint.  We could implment this by factroing
    the repaint method into color-repaint and mono-repaint methods, and
    incure no cost in performance.

Geometry management
    Right now there is a lot of extra computation being done in gm's.
    We need to clean up the protocol.  Also, we need to make gm's listen to
    the resize increment, look at borders/labels (see below) and expand the
    concept of a resize hint to include:
	o base-size - the absolute minimum size a widget should be
	o widget-req-size - the widgets preferred size
	o user-req-size - the user preferred size for a widget

Labels
    These are a great idea that need to be both integrated better into
    the system.  Right now, only a few gm's know about labels and how
    to manage them.  We've also kicked around ideas about the justification
    of labels and such.  For example, it should be easy to make all the
    labels and widgets left side line up.  

Event Handling
    There are a bunch of things to do here.  Realtime event support and
    support for non-X events are a start.  We also need to change the event
    handling scheme to provide support for visit-orders and such in the form
    of interceptors.

Widgets
    Some of the existing widgets need work, others need to be written.  I'd
    like to take (trivially) create another graphic gadget that allows for
    applications to draw inside a window.  GIF widgets need a bunch of
    colormap options.  Multifont text would be nice.  The list is
    probably semi-infinite.

Browsers
    We might want to add another element to the widget/gadget/synth
    categories: a browser.  A lot of our applications use objects
    which display a complex data structure, allow for moving, selecting,
    and searching.  Why have a browser?  Conceptual clarity, modularization
    of code, and does anyone want to write a multifont text *editor* real
    soon (where's Chung :-)?

Class hierarchy changes
    The class hierarchy needs to be reworked.  Gadgets are no more 
    than an abstract class, and could easily be removed or put directly
    into a single inheritance tree below window.  After all, if it's
    only an abstract class, we can insert it in the hierarchy between
    window and x-window.  X-window, opaque-window and widget could all
    be callapsed into the widget class.  Since this will become a
    relatively static single inheritance tree, methods can be replaced
    with function calls on the internal, frequently used methods (eg,
    new-instance).  By making the top levels of the class hierarchy
    single-inheritance and removing some of the extraneous classes,
    we could probably buy some performance.

Port to C
    Just kidding.
