%Doc-1.0
\documentstyle{report}

%textwidth 468pt
%textheight 684pt
%columns 3
%counter{section} = 5
%label{introduction}{6}

\begin{document}
%
%
\figure*{{\bf {\LARGE {\align{left}Glyphs:\hrule
Flyweight Objects for User Interfaces\font{Times-Roman}\size{10}\align{center}\\
}}}%90.24 -18.2401 0
}%
%
%
%
\section{Introduction}%
%
Most user interface toolkits are object-oriented because program objects
are a natural way to represent the objects that a user manipulates.
However, current toolkits have shied away from a whole\--hearted com\-mit\-ment
to the object-oriented model. These toolkits pro\-vide ob\-jects such
as but\-tons and menus that let pro\-gram\-mers build inter\-fac\-es
to appli\-ca\-tion com\-mands, but they do not pro\-vide ob\-jects
for build\-ing\label{introduction} in\-ter\-faces to a\-ppli\-ca\-tion
data. Without this support, programmers must often define many new
components from scratch; the savings afforded by the toolkit is offset
by the cost of handcrafting the new components.%
%
\figure{\begin{tabular}{|l|c|r|}
\hline
Request&
{\bf preference}&
10\\
\hline
Allocates &
{\align{justify}size}&
20\\
\hline
Draw&
appearance&
30\\
\hline
\end{tabular}%
\medskip
Glyph protocol\smallskip
%332.16 -641.28 0
}%
%
%
%
\subsection{Overview}%
%
To offer the full benefits of an object-oriented model, a toolkit
must encourage programmers to use objects for even the smallest components
in the interface. Current toolkits let programmers build interfaces
that contain hundreds of objects. But to reflect the fine-grained
structure in application data, programmers may need hundreds of thousands
of objects. For example, text is logically composed of characters,
so a text view should be built from objects that represent individual
characters. A moderate-sized document, such as a technical paper or
a chapter in a book, will need at least 50,000 character objects.%
%
\subsection{Other toolkits}%
%
Most user interface toolkits are object-oriented because program objects
are a natural way to represent the objects that a user manipulates.
However, current toolkits have shied away from a whole\-hearted com\-mit\-ment
to the object-oriented model. These toolkits pro\-vide ob\-jects such
as but\-tons and menus that let pro\-gram\-mers build inter\-fac\-es
to appli\-ca\-tion {\em com\-mands}, but they do not pro\-vide ob\-jects
for build\-ing in\-ter\-faces to a\-ppli\-ca\-tion {\em data}. Without
this support, programmers must often define many new components from
scratch; the savings afforded by the toolkit is offset by the cost
of handcrafting the new components.%
%
\figure{%
\psfig{figure=car.ips,width=2in}%
%319.68 -211.2 0
}%
%


\quad This approach can dramatically simplify an implementation, but
it is practical only if objects are simple and cheap. The combination
of faster hardware and more efficient object-oriented languages has
now made it possible to use objects at this finer level of granularity
without sacrificing interactive response.

\quad We have designed a set of ``flyweight'' components, called glyphs,
that are simple and efficient. The Glyph base class defines a protocol
for drawing; subclasses define specific appearances such as graphic
primitives (lines and circles), textual primitives (words and spaces),
and composite objects (tilings and overlays). Applications define
their appearance by building hierarchies of glyphs.%
%
\figure{{\center \smallskip
\psfig{figure=objects.ips,width=3in}%
\medskip
TextView object structure\smallskip
}%198.72 -51.8401 0
}%
%


\quad We have implemented glyphs as an extension to the the InterViews
toolkit, which is written in C++. The glyph class hierarchy is currently
independent of other InterViews classes, but we plan to restructure
InterViews so that the Interactor class derives from Glyph. To show
that glyphs are practical, we have implemented a WYSIWYG document
editor that creates a glyph for each character in the text.%
%
\figure{\hrule
%
\begin{verbatim}

TextView::TextView(FILE* file) {
  TBBox* page = new TBBox();
  LRBox* line = new LRBox();
  int c;
  while ((c = getc(file)) != EOF) {
    if (c == '\n') {
      page->append(line);
      line = new LRBox;
    } else {
      line->append(new Character(c));
    }
  }
  body(page);
}

\end{verbatim}%
\hrule
\smallskip
A TextView built from glyphs\smallskip
%43.2 -492.48 0
}%
%
 \quad In section~1 we show how to build a text view using glyphs.
We start with a simple ASCII file viewer and evolve it to a view that
supports multiple fonts and multiple column formatting. Section~2
discusses the glyph class design in more detail, and section~3 describes
how it can be implemented efficiently. In section~4, we compare our
text view with similar components provided by other toolkits.%
%
\figure{\smallskip
\psfig{figure=flag.oz.ips,rotate=90,height=2.5in}%
\smallskip
%168 0.960205 1
}%
%


\quad \quad We have implemented glyphs as an extension to the the
InterViews toolkit, which is written in C++. The glyph class hierarchy
is currently independent of other InterViews classes, but we plan
to restructure InterViews so that the Interactor class derives from
Glyph. To show that glyphs are practical, we have implemented a WYSIWYG
document editor that creates a glyph for each character in the text.

\quad We have implemented glyphs as an extension to the the InterViews
toolkit, which is written in C++. The glyph class hierarchy is currently
independent of other InterViews classes, but we plan to restructure
InterViews so that the Interactor class derives from Glyph. To show
that glyphs are practical, we have implemented a WYSIWYG document
editor that creates a glyph for each character in the text.

\quad We have implemented glyphs as an extension to the the InterViews
toolkit, which is written in C++. The glyph class hierarchy is currently
independent of other InterViews classes, but we plan to restructure
InterViews so that the Interactor class derives from Glyph. To show
that glyphs are practical, we have implemented a WYSIWYG document
editor that creates a glyph for each character in the text.

%
\end{document}