\documentstyle[11pt]{article}
\setlength{\topmargin}{0.5 in}     % try to get 0.5'' top and bottom margin
\setlength{\textheight}{8.5 in}
\setlength{\footskip}{.5 in}
\setlength{\footheight}{1 in}
\setlength{\headsep}{0pt}
\setlength{\headheight}{0pt}
\begin{document}

\begin{tabular}{c}
\large \bf
A Comparison of Two Currently Available X11 Toolkits \\
by Mark Lillibridge \\
June 29, 1988
\end{tabular}

\section{Introduction}

	At this time there are only two general purpose toolkits
publicly available for X11.  These are the Andrew Toolkit from
CMU\footnote{Carnegie Mellon University} and the Digital Equipment
Corporation's X Toolkit.  This document attempts to compare the two {\em
as they currently exist and are documented\/} from the perspective of the
applications writer who wants to start writing code today.  In
particular, this document was written to help answer the question ``I
want to write an application to do Xyz under X11.  What toolkit if any
should I use?''

\section{Similarities}

	Both of these toolkits were designed to solve the same class of
problems, namely building applications with user friendly graphical
interfaces, so it is hardly surprising that they should be similar in
many respects.  For the most part, they embody the same concepts and
ideas such as the use of object-oriented programming, event-driven
dispatching, and the reuse of objects through various means of
combination.  This is due to convergent evolution and the fact
that both used proven ideas and lessons from previous toolkits.
However, the fact remains that the main differences between the two
toolkits lie not in their ideas or concepts, but rather in their
implementations.  For example, the two toolkits differ on what standard
objects they provide and how portable they each are.

\section{Differences}

\subsection{Tech Level}

	By Tech Level, I mean the relative high or low level of the
operations and objects provided by each toolkit.  The analogy here is
with programming languages.  A high-level language allows the programmer
to perform operations that are much closer to the application's domain
than to the primitive machine's operations.  For example, in an AI
program, a high level language might directly support operations like
``attempt to deduce the following fact.''  The same operation would have
to be done in a low level language by thousands of primitive operations
requiring a great deal more programming work.  A similar concept applies
to toolkits.

\vspace{.1 in}
	For example, a high level toolkit might support directly the
operation ``get a filename from the user'' while a low level toolkit
would require the same operation to be done using a series of create
object, combine object, pop-up object, interact with user, etc. calls.
A higher level toolkit has several advantages over a lower level one.
First, it removes the need for the programmer to keep constantly
reinventing the wheel by providing standard routines for all the common
interface needs.  Second is the fact that by providing standard
routines, use of the same toolkit for a variety of applications ensures
that they use a consistent interface making things much easier for the
users which do not then have to keep relearning how to scroll text, etc.
for each new application.

\vspace{.1 in}
	The Mac's user interface provides a good example of the kind of
consistency that can be achieved by the use of a single high level
toolkit with high level operations to create alert boxes, update the
menu bar, and so on.  Another advantage of using a high level toolkit is
that by separating the details of how the interface is implemented
(i.e., just how {\em should} a scroll bar work?) from what it is supposed
to do, it becomes possible to change the actual interface's workings
without having to change any of the application's code.  This is a major
advantage because it means the interface can be improved as time goes on
without having to update all the applications.  Of course, if the
programmer disagrees with the toolkit's way of implementing its high
level operations, a different interface can always be implemented using
low level operations at the cost of losing all of the above benefits.

\vspace{.1 in}
	So how do ATK\footnote{This is the standard abbreviation for the
Andrew Toolkit.} and DXT\footnote{This is an abbreviation for the
Digital Equipment Corporation X Toolkit.} stack up on this scale?  Well,
since one of the major design goals of DXT is a ``policy free
implementation,'' it is forced by design to be a low level toolkit.
ATK, on the other hand, is a fairly high level toolkit although not as
high level as it could be.  ATK provides easy operations for multi-font
text, getting filenames, displaying error messages, prompting the user
for text, and displaying pop-up menus.  Some of these are doable using
DXT by means of a lot of operations while others are currently not
doable except by ``assembler language'' --- i.e., raw Xlib calls.  In
particular, DXT does not currently support multiple font text in any
way.  This difference in tech level is a major difference between the
two toolkits which is likely to remain for the foreseeable future.

\subsection{Current Implementation Limitations}
	Unfortunately, while the Andrew Toolkit has many high level
operations, it currently omits many of the low level operations which
would be needed to build its high level operations.  For instance, ATK
provides high level operations to bind names to procedures using pop-up
menus but does not provide the low level operations needed to construct
a menu in the first place.  This makes no real difference so long as the
programmer uses the ATK user interface style and its associated
high-level operations.  However, if the programmer feels ATK's user
interface policy is too limiting or ``wrong,'' it is not currently an
easy matter to implement an alternate policy.  This is an important
difference now but is likely to become less so as time goes on and the
missing operations are added to ATK.

\vspace{.1 in}
	ATK currently also suffers from another class of limitations due
to the fact that it is intended to be window system independent.  In
order to achieve this, ATK has added its own layer of abstraction over
raw Xlib.  However, this layer is far from complete.  Many of the more
obscure features of X11 such as dashed lines, stipple fill, and 16 bit
fonts which are not found in any other window system are not currently
accessible from ATK's graphics layer.  This means that unless you modify
the toolkit or break lots of abstraction barriers you will not be able
to use these features in ATK.  These limitations will undoubtly be fixed
when CMU gets around to them but for now they render ATK unusable for
some applications.

\vspace{.1 in}
	DXT also has its share of limitations.  The only really major
ones, however, all have to do with the lack of any toolkit-wide policies
to deal with multi-media editors.  (a multi-media editor is an editor
that can edit any kind of data whatsoever whether it be text, a
spreadsheet, or sheet music by invoking an appropriate editor for each
kind of data) Multi-media editors require that all widgets that could be
edited obey a large number of rules so that they can get along as part
of one large editor.

\vspace{.1 in}
	For instance, the editor must be able to ask an embedded widget
to write out its data to a file in ASCII using a standard format so that
it will be able to read it back it.  DXT does not currently have any
such set of rules so that any one attempting to write a multi-media
editor under DXT will quickly run into problems.  Another thing required
by a good multi-media editor is the ability to dynamically load widget
code at run time by widget name.  ATK supports this but DXT does not and
will never do so because it violates another DXT design goal, operating
system independence.

\subsection{Ease of Use}

	Another difference between the two toolkits is their ease of
use.  ATK wins hands down here due to its use of abstraction and a
preprocessor to separate the user from the details of the
implementation.  DXT, alas, does the reverse forcing the user to become
familiar with all the grubby details of the implementation down to the
order of the fields in the various structures!  This is particularly bad
with regard to creating new widgets.  The list of rules concerning the
naming of the various types used for each widget alone runs to three
pages.  This is so bad that I expect novice programmers to avoid
creating new widgets like the plague.  The equivalent in ATK is almost
effortless by comparison.

\subsection{Future Support}

	The last major difference between the two toolkits lies in the
degree of their likely future support.  The only people currently
working on ATK are the people at CMU although more people are likely to
get involved as time goes on.  DXT, on the other hand, in all likelihood
will be ``blessed'' by the X consortium in the near future as the
official X toolkit.  This will mean that it will be the default toolkit
for a lot of people and will ensure that a lot of people and companies
will be working on improving it.

\vspace{.1 in}
	ATK has no where near as great a chance of becoming a standard
at this level.  Also, since DXT is portable across languages and
operating systems whereas ATK is portable only across window systems, it
will have a larger user base in all likelihood.  This makes a difference
because currently both toolkits are far from complete.  The more support
a toolkit has, the faster it will be completed and the more features it
will have added to it.

\section{Conclusion}

As with most comparisons of this nature, there is no overall winner.
For an applications writer who wants to implement a multi-media editor,
ATK is the best choice.  On the other hand, for an applications writer
who wishes to implement a radically different user interface policy, DXT
is the best choice.  Each individual developer must take the strengths
and weaknesses of the two toolkits weighted according to his
application's needs into account when choosing a toolkit.  Only in this
way can a developer be assured of making the best choice for his needs.

\end{document}
