CLIM mail archive
[Prev][Next][Index][Thread]
re: draft for Garnet FAQ
I would like to reply to a few things that Brad Myers said about CLIM in
his draft FAQ posting. I do not intend to criticize Garnet, which is a
valuable contribution to the UI community, but I would like to point out
that CLIM, in many ways, is no less valuable and is no less ambitious,
although its ambitions take a very different direction from Garnet.
Please note that while I am expert in CLIM, I am not a Garnet user. I
have read the papers, but that does not confer any expertise in Garnet
at all. I apologize in advance for any misunderstandings I may have
about Garnet.
------------------------------------------------------------------------
[8] Why doesn't Garnet use CLOS?
CLOS is the standard Common Lisp Object System, and Garnet uses a
custom object system (called KR) instead. There are a number of
reasons for this.
The main reason is that Garnet uses a prototype-instance model, rather
than the conventional class-instance model supported by CLOS. We have
found the prototype model to be more effective for user interface
prototyping and construction. A second reason is performance: it
appears that KR is more efficient than CLOS for most standard
operations.
I'll say just one thing about the non-use of CLOS here, too. Right now,
CMU CL uses PCL rather than a carefully tuned "native" implementation of
CLOS. There is nothing wrong with this (since I presume that the CMU CL
group meant to concentrate on their compiler technology rather than on
CLOS), but CLOS implementations that are highly tuned can be very fast
indeed. All the major commercial implementations of CLOS perform very
well, even when compared against ordinary function calling and accesses
to slots in "ordinary" (non-CLOS) structures.
Since we have control of KR, we can also optimize the
performance of constraint satisfaction, which would require extra
overhead in CLOS.
It is probably true that making slot access do constraint satisfaction
would require some extra overhead, although I strongly suspect that this
could be done very efficiently in CLOS as well.
There are no plans for a CLOS version of Garnet, although we are
thinking about easier mechanisms to link Garnet objects and an
application's CLOS objects.
------------------------------------------------------------------------
[9] How does Garnet compare to CLIM?
Garnet and CLIM are both systems for helping create user interface software in
Lisp for X/11. Both emphasize support for the insides of application windows
(the application-specific graphics). However, there are important
differences, and this section briefly compares these two systems.
CLIM does not in fact emphasize "application-specific graphics". CLIM
emphasizes the overall operation of the application itself, as defined
by the objects in the application that participate in the user interface
and the UI-visible operations on those objects. Unfortunately, this is
a little hard to describe without resorting to lots of examples.
In CLIM, programmers need not spend much programming effort describing
the exact appearance of the user interface, since CLIM manages a lot of
that automatically. If necessary, programmers can override CLIM's
decisions on appearance issues. Instead, programmers write ordinary
CLOS methods that describe the visual appearance of objects in their
application. The appearance of an object can be textual or graphical,
or whatever, but the important point is that CLIM remembers what
application object is associated with any given piece of output, no
matter what its appearance.
Then programmers write "commands" that describe the operations on the
objects of the application. Rather than specifying the "syntax" of
these commands, the programmer specifies only the semantics: what
classes of objects the command takes, and what operations it performs.
These commands can be accessed via menus, dialogs, direct manipulations,
or command lines. In many traditional toolkits, "commands" operate on
objects in the toolkit, but in CLIM commands operate on the application
objects themselves. Furthermore, CLIM takes care to ensure that, when a
commands is invoked, all of its arguments are guaranteed to be objects
of the correct type.
The most significant difference is that Garnet is being developed as a
research tool, whereas CLIM is a commercial product. Therefore, CLIM
costs money, whereas Garnet is distributed for free by anonymous FTP.
Garnet is more ambitious and contains more innovations.
It is true that Garnet contains innovations in the description of the
graphical parts of a user interface. However, CLIM contains many as
well, particularly in the area of directly coupling the semantics of an
application with its user interface. CLIM is also innovative in its
"adaptive toolkit", which is a high level way of describing a toolkit-
style interface in a way that is completely independent of the toolkit
actually being used to implement the look-and-feel. Furthermore, CLIM
2.0 is highly extensible. Most of CLIM's internal protocols are part of
the advertised programmer interface, so programmers can tailor many parts
of CLIM (not just the look-and-feel) to their exact specifications. CLIM
also provides very sophisticated facilities for context-based "mouse
sensitivity", documentation, and help.
CLIM had been
"endorsed" by many of the major Lisp manufacturers, and they will
support and sell CLIM on top of their Lisps. CLIM runs on X/11 or the
Macintosh, whereas Garnet (currently) only runs on X/11.
More accurately, CLIM runs on Motif, OpenLook, the Mac, Microsoft
Windows, "raw" X/11, and Genera. CLIM adapts to the look-and-feel of
each of the window systems it is running under, or in the case of X/11
and Genera, CLIM implements its own portable look-and-feel (which is a
hybrid of Motif and OpenLook). CLIM 1.1 is being sold right now by
Symbolics, Franz, Lucid, and Harlequin. CLIM 2.0 is in beta test by
Symbolics and Franz, and will be released in the spring of 1993. Other
vendors will release CLIM 2.0 in the same time frame.
Garnet, by its very design, is intended to be a higher level
toolkit than CLIM, and to provide more comprehensive support for applications.
I'm afraid I will have to be contentious and deny this claim outright.
Garnet, by its design, has a very high-level way of specifying the
_appearance_ of a user interface. CLIM, by its design, has a very
high-level way of specifying the _behavior_ of the user interface.
These are very different goals. In my opinion, CLIM's design make it
far more able than Garnet to provide comprehensive support for building
complex, real-world applications.
Garnet specifically is designed to allow the user interface designer to
explore new toolkits, looks-and-feels, and to support creation of higher-level
tools, whereas CLIM, because of its commercial aspirations, is intended to use
existing toolkits and provide only minimal support for authoring new
ones.
In my opinion, this is the most significant difference between Garnet
and CLIM, and this has little to do with CLIM's commercial aspirations.
Garnet, as Brad says, has as its main goal the ability to explore and
design new toolkits and looks-and-feels. The people working on CLIM
decided that we would prefer to leverage off the work of the many people
already working on looks-and-feels, and provide a toolkit that offered
something that goes beyond just managing look-and-feel. It is true that
CLIM provides only minimal support for authoring new toolkits, but that
is not one of its main goals. CLIM's primary goal is to support
programmers in rapidly bringing up portable applications to fit into a
standard environment, and it meets these goals quite well.
Some people have reported that Garnet seems to run faster than CLIM.
But only your profiling facility knows for sure :-).
CLIM grew out of the Symbolics style of programming, and uses the nomenclature
and techniques of Symbolics, whereas Garnet grew out of the user interface
toolkit world. As a result, it is often difficult to compare the two since
they use similar terms for different concepts. Another result is that users
of Symbolics might feel more comfortable with CLIM, whereas users of other
toolkits, like Xt and the Macintosh toolkit, might find Garnet more
understandable.
I certainly agree that programming interfaces in CLIM is quite different
from programming in toolkits like Xt and the Mac, but people who use
CLIM quickly learn that those differences buy them a lot of power.
In terms of features, there are a large number of differences. Garnet
integrates a constraint solver with the object system, so that any
slot (instance variable) of an object can contain an arbitrary Lisp
expression, which is automatically re-evaluated when any referenced
object changes.
Garnet's constraint-solving mechanisms are another of its strengths, but
remember that this is not intended to be part of CLIM itself. Some of
the people working on CLIM have also done some work on a higher-level
toolkit that supports inter-object constraints that can be mediated by
the application.
CLIM version 2.0 has some support for re-laying-out
of the panes of an application based on external changes to the screen
geometry or internal changes in the widgets in a pane, but still does
not offer full constraint solving.
While this is true, in practice, CLIM's mechanisms seem to be quite
adequate for most (if not all) of the people who are now using it. Of
course, it remains to be seen whether those people will eventually need
more power in this area than CLIM now provides.
Garnet provides high-level support
for handling interactive behaviors through special mouse and keyboard
handling objects.
To the best of my understanding, in Garnet these ``interactors'' are
reified objects, whereas in CLIM this behavior is provided automatically
by an internal higher-level event processing layer. But CLIM provides
high-level support in this area also.
Both Garnet and CLIM hide the X/11 interface from
the application, and provide an object-oriented interface instead.
To the best of my understanding (again), the objects in Garnet are
hybrid objects consisting partly of toolkit state and partly of
application state. In CLIM, toolkit classes and application classes do
not need to be "mixed in" to each other, which maintains a clean
boundary between the application and its UI, meaning that application
objects do not need to obey protocols that are rightly part of the UI,
and toolkit objects to not need to obey application protocols. Instead,
CLIM "presentations" mediate between the application and the UI. Of
course, since CLIM is extensible, application objects may participate in
UI protocols, but doing this is not a requirement.
In
Garnet, however, composite (application-specific) objects can be
created declaratively just by listing the component parts and the
constraints that hold them together. The objects can sometimes even
be created interactively using some of Garnet's higher-level tools.
In my opinion, this is one of the very strong points of Garnet.
CLIM uses a more conventional strategy where programmers must write
methods to define the components. Both Garnet and CLIM provide
mechanisms to automatically lay out objects in tables, graphs and
trees. CLIM uses the standard CLOS object system, whereas Garnet
invents a new prototype-instance object system, with a number of
interesting properties. However, Garnet's object system can co-exist
with CLOS in the same Lisp image, if desired.
As a language implementor, I think that having two object systems
around, one for the application and one for the UI, is bound to cause
confusion and extra work for programmers and maintainers.
At the widget level, Garnet provides two full sets of widgets implemented
entirely in Lisp. One has the Motif look and feel. Because they are
implemented on top of the Garnet intrinsics, it is quite easy to add new
widgets, customize existing widgets, or create an entirely new look and feel
(the entire Motif look and feel was implemented in a few weeks).
Actually, CLIM 2.0 does provide a portable widget set (including scroll
bars, sliders, push buttons, toggle buttons, radio and check boxes, list
and option panes, text editing panes, and window "decoration" panes).
Furthermore, CLIM 2.0 running on Motif (under Franz Allegro, for example)
has a complete Motif look-and-feel, because it uses Motif directly.
Since CLIM 2.0 just uses Motif directly, it will always be fully up to
date w.r.t. the Motif look-and-feel. The same is true of CLIM 2.0 on
OpenLook (under Allegro or Lucid CL, for example). Symbolics is also
developing CLIM 2.0 for Microsoft Windows, and Illudium is developing it
for the Mac; the appropriate look-and-feel will be in force under those
toolkits as well.
Garnet
also provides widgets that no other toolkit does, such as one that
automatically provides the move and grow handles on graphical objects. Other
high-level widgets in Garnet include a property-sheet, a multi-pane browser,
scrolling-windows, etc. CLIM does not currently provide any widgets, but
future releases are expected to call out to the regular Motif, OpenLook and
Macintosh Toolbox libraries written in other languages.
I feel that gadgets such as move and grow handles for graphical objects
are more properly the domain of a graphical-editing toolkit, since they
are not generally useful except in applications that do graphical
editing. As such, I do not believe that they belong in CLIM proper.
The toolkit I alluded to above encapsulates such widgets.
Garnet provides three high-level tools, including an interface
builder, whereas CLIM has no high-level tools.
It is true that CLIM does not now have any higher-level tools. This is
a manpower constraint, not a design constraint. I confess to being
quite jealous of the tools that Garnet provides...
0,,
Main Index |
Thread Index