Several people sent me mail for a summary of LispView vs CLIM thread and
also enquering about my choice between the two packages. Therefore, I
am enclosing those articles that I saved.
My choice between LispView or CLIM is relevant to my own circumstances;
both systems appear to be well thought out and well implemented
products. LispView is particularly attractive because its free. The
LispView run time image may be smaller than CLIM and *might* be faster
on small machines. It implements XView look and feel, which might be
important in some circumstances. Furthermore, LispView source is more
or less unencumbered, so it might be possible to port it to run on top
of AKCL or other public domain lisps to get a completely free lisp +
interface system. Nonetheless, after considering all factors, I choose
to use CLIM.
The single most important reson for selecting CLIM is that CLIM is based
on the accept-present paradigm, while LispView is a widget based
library. The accept-present paradigm [in my presonal opinion]
represents a conceptual breakthrough. This is not to suggest that
LispView is "bad", I am only suggesting that it is conceptually and
functionally equivalent to facilities provided to C programmers in XView
libraries. The power of the accept-present paradigm is not obvious
until you try it. I have just finished a small system written in
Flavors and Dynamic Windows which is based on the presentation system.
This has saved me thousands of line of code and gave me a very flexible
easy to extend product. So, at this stage, I am very enthusiastic about
CLIM which is also presentation based.
Lastly, the fact that CLIM is portable and broadly supported outweighed
any potential disadvantage of the added cost.
Once more, thank you to all whose responses appear below,
Leslie Walko
······@bellcore
Comp. Sci. Res. Lab
Bell Communications Research
--------------------------------------------
From ·····@liasun2.epfl.ch Fri Nov 15 6:13:49 1991
Subject: lispview vs clim
Date: 15 Nov 91 11:13:49 GMT
From: ·····@liasun2.epfl.ch (Simon Leinen)
Newsgroups: comp.lang.lisp
Sender: ····@disuns2.epfl.ch
Organization: DI-LIA -- Ecole Polytechnique Federale de Lausanne
Reply-To: ·····@liasun6.epfl.ch
In-Reply-To: ········@liasun3.epfl.ch's message of 15 Nov 91 07:36:26 GMT
Message-Id: <···················@liasun5.epfl.ch>
References: <······················@walter.bellcore.com> <····@skye.ed.ac.uk>
Lines: 48
Id: 6108
Path: walter!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!mcsun!cernvax!chx400!sicsun!disuns2!disuns2.epfl.ch!simon
In article <····@disuns2.epfl.ch> ········@liasun3.epfl.ch (Emmanuel
Baechler) writes:
There is another difference: LispView works only with Lucid while
CLIM works with Allegro, Harlequin, Mac CL and Symbolics.
Unfortunately this is true at the moment---but the LispView source has
been released to the public just a week ago. I have looked at the
source and porting it to another CL dialect seems not too difficult,
but not a two-hour hack either. According to the README, "porting
should be feasible". Basically you have to replace Lucid's foreign
(C) function interface by your Lisp's and do some cleanup. Arguments
to port LispView to your favourite Lisp include:
* it is itself freely available unlike e.g. CLIM.
* it is already based on a free UI Toolkit (XView), unlike e.g. CLM,
which is based on MOTIF.
* it already implements a "standard" Look&Feel (Open Look(TM)),
unlike some current versions of CLIM. It must be said that CLIM
moves in that direction, and prototype CLIM backends for MOTIF and
Open Look (also based on XView) exist already, as well as versions
under MS Windows and the Mac UI, whatever it's called. On the
other hand, porting LispView to another L&F would probably be very
difficult because it is based on XView rather than the X Toolkit.
* it is based on state-of-the art X technology unlike e.g. CLUE
(personally I prefer CLUE's Xt-like prgramming paradigm, but it
never caught up with MIT's Xt development effort).
Personally, I would like to see LispView ports appearing for the free
CLs (CMU Common Lisp and (A)KCL). So if you are looking for a CL user
interface toolkit and for some reason don't like what is available
(CLIM, CLM, CLUE), and don't have Lucid Common Lisp, why not simply
port LispView? You could do the Lisp world (except for ILA, that is
:-) a favour by making your port publicly available. I'd be happy to
provide disk space on our FTP server.
In other words, CLIM is a "de facto" standard.
Oh well, that's what the CLIMmers call it. But it's not the only one,
and I certainly would not mind having one more "de facto" standard UI
Toolkit, especially one that's free.
--
Simon Leinen.
Laboratoire d'Intelligence Artificielle
Ecole Polytechnique Federale de Lausanne
------------------------------------------------------------------------
From ·····@liasun2.epfl.ch Fri Nov 15 6:13:49 1991
Subject: lispview vs clim
Date: 15 Nov 91 11:13:49 GMT
From: ·····@liasun2.epfl.ch (Simon Leinen)
Newsgroups: comp.lang.lisp
Sender: ····@disuns2.epfl.ch
Organization: DI-LIA -- Ecole Polytechnique Federale de Lausanne
Reply-To: ·····@liasun6.epfl.ch
In-Reply-To: ········@liasun3.epfl.ch's message of 15 Nov 91 07:36:26 GMT
Message-Id: <···················@liasun5.epfl.ch>
References: <······················@walter.bellcore.com> <····@skye.ed.ac.uk>
Lines: 48
Id: 6108
Path: walter!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!mcsun!cernvax!chx400!sicsun!disuns2!disuns2.epfl.ch!simon
In article <····@disuns2.epfl.ch> ········@liasun3.epfl.ch (Emmanuel
Baechler) writes:
There is another difference: LispView works only with Lucid while
CLIM works with Allegro, Harlequin, Mac CL and Symbolics.
Unfortunately this is true at the moment---but the LispView source has
been released to the public just a week ago. I have looked at the
source and porting it to another CL dialect seems not too difficult,
but not a two-hour hack either. According to the README, "porting
should be feasible". Basically you have to replace Lucid's foreign
(C) function interface by your Lisp's and do some cleanup. Arguments
to port LispView to your favourite Lisp include:
* it is itself freely available unlike e.g. CLIM.
* it is already based on a free UI Toolkit (XView), unlike e.g. CLM,
which is based on MOTIF.
* it already implements a "standard" Look&Feel (Open Look(TM)),
unlike some current versions of CLIM. It must be said that CLIM
moves in that direction, and prototype CLIM backends for MOTIF and
Open Look (also based on XView) exist already, as well as versions
under MS Windows and the Mac UI, whatever it's called. On the
other hand, porting LispView to another L&F would probably be very
difficult because it is based on XView rather than the X Toolkit.
* it is based on state-of-the art X technology unlike e.g. CLUE
(personally I prefer CLUE's Xt-like prgramming paradigm, but it
never caught up with MIT's Xt development effort).
Personally, I would like to see LispView ports appearing for the free
CLs (CMU Common Lisp and (A)KCL). So if you are looking for a CL user
interface toolkit and for some reason don't like what is available
(CLIM, CLM, CLUE), and don't have Lucid Common Lisp, why not simply
port LispView? You could do the Lisp world (except for ILA, that is
:-) a favour by making your port publicly available. I'd be happy to
provide disk space on our FTP server.
In other words, CLIM is a "de facto" standard.
Oh well, that's what the CLIMmers call it. But it's not the only one,
and I certainly would not mind having one more "de facto" standard UI
Toolkit, especially one that's free.
--
Simon Leinen.
Laboratoire d'Intelligence Artificielle
Ecole Polytechnique Federale de Lausanne
------------------------------------------------------------------------
From ········@bbn.com Fri Nov 15 21:39:45 1991
Subject: lispview vs clim
Date: 16 Nov 91 02:39:45 GMT
From: ········@bbn.com (Jeff Palmucci)
Newsgroups: comp.lang.lisp
Sender: ····@bbn.com
Message-Id: <·····@bbn.BBN.COM>
References: <······················@walter.bellcore.com> <····@skye.ed.ac.uk> <···················@liasun5.epfl.ch>
Lines: 88
Id: 6109
Path: walter!uunet!paladin.american.edu!darwin.sura.net!udel!rochester!news.bbn.com!bbn.com!jpalmucc
Now, wait a minute.
There are other differences between LispView and CLIM besides
licensing and platform availability.
Its seems to me that the philosophy behind each implementation is
completely different. LispView is definitely a widget-based interface,
whereas CLIM is a dynamic windows clone.
LispView has no concept of context-sensitive input or presentations.
It cannot handle mouse-events to answer something like (accept
'pathname), because it has no concept of what pathnames are, and where
they may be displayed on the screen. CLIM, however, can return from
the accept just by clicking on a pathname (any pathname) that happens
to be on the screen at the time.
CLIM does automatic input checking. If you ask for a pathname in CLIM,
a user will not be able to enter in anything that doesn't look like a
pathname. In LispView, you must write your own input checking routines.
This kind of context-sensitive input is not limited to predefined lisp
types. Programmers can define their own presentation types that
check any input to make sure it represents a valid input. Any CLIM
component that prompts for this user-defined object will automatically
use this input checking. This makes much more robust user interfaces.
LispView can't do accepting-values. If I want to make a dialog in
CLIM, all I do is:
(clim:accepting-values (stream :own-window t)
(let ((count (clim:accept 'integer :stream stream)))
(loop for count from 1 to count
collect (clim:accept 'string :stream stream))))
Which will pop up a dialog and prompt for a number, and any number of
strings. In fact, the dialog will *dynamically restructure itself*
based on how many strings are required.
On the other hand, LispView does some things better than CLIM.
LispView gives the programmer much more control over how the interface
looks. You can make dialogs that have slide bars, gauges, scroll
lists, etc. I can see how this can be done in CLIM, but the
functionality is not there as a standard component.
In conclusion, CLIM knows much more about the underlying data
structure of objects presented to the screen. It has its own methods
for dealing with these structure, and it may be difficult to
substitute your own. For example, the default method for inputing an
integer in some range is to type in the integer, which will be checked
to make sure it in is the proper range. In order to replace this with
a slide bar, you would have to write your own presentation type, and
implement the slide bar by hand (at least in the CLIM release that I
have used).
LispView, on the other hand, knows much more about fancy interface
components. Slide bars are already implemented for you. LispView is
also MUCH smaller. It uses C libraries for the bulk of its operation.
These two packages support different types of interface philosophies.
CLIM supports the Symbolics (>= rel 7) philosophy in which everything
is mouse sensitive. Anything that is presented has some semantics
associated with it, which can be used by other parts of the interface.
LispView supports the X/Motif/Open look philosophy, which is more
iconic, and prettier. I feel, however, that some functionality was
lost.
Later
Jeff
PS Its a shame that more people don't know about/use Genera style
interfaces. If they did, CLIM functionality would be in many more GUI
toolkits. I was fairly bummed using Lucid for the first time after
working on Symbolics.
PPS LispView only works under lucid (although that will probably
change) and under Open Look (which will probably not). From the legal
notice accompanying the LispView release:
> NOTICE TO USER: The materials in this directory, including source
> code, object code, and documentation, including the glyphs or icons
> forming a part of the OPEN LOOK(R) Graphic User Interface, on this
> tape and in these files is copyrighted under U.S. and international
> laws. Sun Microsystems, Inc. of Mountain View, California owns the
> copyright and has design patents pending on many of the icons. ...
Does this mean that LispView can only be used to make Open Look
applications, or does it mean that you can't modify the Open Look
------------------------------------------------------------------------
Leslie A. Walko
From: Jeff Dalton
Subject: Re: lispview vs clim : summary
Date:
Message-ID: <5662@skye.ed.ac.uk>
>LispView has no concept of context-sensitive input or presentations.
>It cannot handle mouse-events to answer something like (accept
>'pathname), because it has no concept of what pathnames are, and where
>they may be displayed on the screen. CLIM, however, can return from
>the accept just by clicking on a pathname (any pathname) that happens
>to be on the screen at the time.
In almost any system, the user can pick up printed representations
of Lisp objects with the mouse and give them to Lisp. That isn't
as nice as what CLIM offers, but neither is it completely useless.
From: Jeff Palmucci
Subject: Re: lispview vs clim : summary
Date:
Message-ID: <67467@bbn.BBN.COM>
····@aiai.ed.ac.uk (Jeff Dalton) writes:
>>LispView has no concept of context-sensitive input or presentations.
>>It cannot handle mouse-events to answer something like (accept
>>'pathname), because it has no concept of what pathnames are, and where
>>they may be displayed on the screen. CLIM, however, can return from
>>the accept just by clicking on a pathname (any pathname) that happens
>>to be on the screen at the time.
>In almost any system, the user can pick up printed representations
>of Lisp objects with the mouse and give them to Lisp. That isn't
>as nice as what CLIM offers, but neither is it completely useless.
True,
I think of LispView as something similar to the Symbolics Release 6
window system. It is definitely not useless. Mouse clicks can be
sensed and dispatched fairly easily, it is easy to tell which object a
mouse click hit, there are standard facilities for dialogs, etc.*
LispView, however does not know what screen objects are beyond
"slider" or "button". It is up to the programmer to connect the
buttons and select the appropriate actions. You probably can hardwire
in the context sensitivity that CLIM gives you, but it would be a
large job.
Furthermore, I *really* like CLIM's ability to restructure dialogs
based on content. The application looks much more intelligent to the
user if it can reformulate its queries to avoid asking stupid
questions. Also, you can build a dialog in CLIM as easy as you can
read something from the listener. An application programmer doesn't
even need to know that there is a dialog object.
Oops, it looks like I just restated my original posting. Maybe I
should delete this one. Nah :-)
Jeff
* I am NOT putting down LispView here. The release 6 window system was
evolved. Because of this, it looks like a messy kludge. From what I
know of LispView (reading through the manual, but never actually using
it), it looks like a well designed and thought out system. It also has
a lot of bells and whistles that release 6 never had. My impression is
that LispView is more useful in creating an application than Symbolics
release 6, but not more useful than Symbolics release >= 7.2 (7.1 was
a dog).
This does not make LispView uncompetitive with CLIM. At the current
time, LispView makes prettier interfaces than CLIM. LispView is also
much smaller (although if your machine is big and fast enough to run a
In article <·····@bbn.BBN.COM> ········@bbn.com (Jeff Palmucci) writes:
> This does not make LispView uncompetitive with CLIM. At the current
>time, LispView makes prettier interfaces than CLIM.
The adaptive toolkit feature of CLIM 2.0 will take care of that. CLIM 2.0
has the ability to translate many CLIM operations to their counterparts in
another toolkit. So far, I believe they've developed interfaces to Motif
(via CLM), XView (via LispView), and the Macintosh Toolkit (using MCL's
built-in interface).
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
In article <····@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
>In almost any system, the user can pick up printed representations
>of Lisp objects with the mouse and give them to Lisp.
Not if the printed representation is of the #<...> form. CLIM has no
trouble with such objects.
Also, for most types, the result of reading the printed representation
isn't EQL to the original object. CLIM preserves identity.
And CLIM doesn't require the object to be output with its standard printed
representation.
I guess these are all part of what you meant when you said:
> That isn't
>as nice as what CLIM offers, but neither is it completely useless.
My UI to Lucid Lisp is an Emacs buffer, and it provides this form of
cut-and-paste. The point of using a higher level GUI such as CLIM is to
provide better.
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
From: Jeff Dalton
Subject: Re: lispview vs clim : summary
Date:
Message-ID: <5670@skye.ed.ac.uk>
In article <············@early-bird.think.com> ······@think.com (Barry Margolin) writes:
>In article <····@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
>>In almost any system, the user can pick up printed representations
>>of Lisp objects with the mouse and give them to Lisp.
>
>Not if the printed representation is of the #<...> form. CLIM has no
>trouble with such objects.
>
>Also, for most types, the result of reading the printed representation
>isn't EQL to the original object. CLIM preserves identity.
>
>And CLIM doesn't require the object to be output with its standard printed
>representation.
>
>I guess these are all part of what you meant when you said:
>
>> That isn't
>>as nice as what CLIM offers, but neither is it completely useless.
That's right. They're part of it.
However, you should note that it's not too hard arrange for many
kinds of objects to have printed representations that can be read
as the same EQL object. Indeed, for some Lisps it would be possible
to define the #<...> notation to do that. Call it a hack if you
will, but it's free and available now.
-- jeff
In article <············@early-bird.think.com> ······@think.com (Barry Margolin) writes:
In article <····@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
>In almost any system, the user can pick up printed representations
>of Lisp objects with the mouse and give them to Lisp.
Not if the printed representation is of the #<...> form. CLIM has no
trouble with such objects.
Also, for most types, the result of reading the printed representation
isn't EQL to the original object. CLIM preserves identity.
And CLIM doesn't require the object to be output with its standard printed
representation.
You can achieve all these effects very cheaply if you modify the
printer and the reader. The printer can prefix objects with a tag
(e.g., ·@173#(1 2 3)"), keep printed objects in a table, and the
reader can look up the object when presented with a tag. I've done
it--it works pretty well.
If you use a program like Emacs or Epoch as your Lisp user interface,
this program could hide the tags and make regions of text mouse
sensitive (in Epoch, you can even highlight them).
This kind of text-based interface has the advantage that it isn't tied
to any particular window system, that it's smaller, that it can be
integrated with Emacs, and that it's easier to implement. I'd actually
prefer this to CLIM or dynamic windows.
Thomas.
From: ···@ai.mit.edu (Thomas M. Breuel)
Newsgroups: comp.lang.lisp
Date: 21 Nov 91 16:16:20 GMT
Organization: MIT Artificial Intelligence Lab
You can achieve all these effects [presentation style input] very
cheaply if you modify the printer and the reader. The printer can
prefix objects with a tag (e.g., ·@173#(1 2 3)"), keep printed
objects in a table, and the reader can look up the object when
presented with a tag. I've done it--it works pretty well.
Doesn't this prevent any objects that are ever printed from being
garbage collected?
- Eric (······@nas.nasa.gov)
In article <····················@wk43.nas.nasa.gov>, Eric Raible writes:
> From: ···@ai.mit.edu (Thomas M. Breuel)
>
> You can achieve all these effects [presentation style input] very
> cheaply if you modify the printer and the reader. The printer can
> prefix objects with a tag (e.g., ·@173#(1 2 3)"), keep printed
> objects in a table, and the reader can look up the object when
> presented with a tag. I've done it--it works pretty well.
>
> Doesn't this prevent any objects that are ever printed from being
> garbage collected?
Sure! But so does CLIM. At least until the `output history' of a
window is cleared. The CLIM output history is what Eric's table
essentially is (or wannabe's :>)
Presumably, part of `modifying the printer' must consist of
clearing the table whenever a ^L (or whatever) is printed ?
I fell into a similar trap in a Dynamic Windows program I wrote where
the interaction pane presented (in short #<..> form) the presentation
object being displayed on the display pane. For some special uses one
might want to diddle with it... well, it made sense at the time!
But, after displaying, then clearing, hundreds of big things on the
display pane, it's easy to forget that all those things were still in the
(scrollable) output history of the interactor -- they weren't GC'd.
Ouch, well it wasn't DW's fault.
In article <····················@wk43.nas.nasa.gov> ······@nas.nasa.gov writes:
> From: ···@ai.mit.edu (Thomas M. Breuel)
> You can achieve all these effects [presentation style input] very
> cheaply if you modify the printer and the reader. The printer can
> prefix objects with a tag (e.g., ·@173#(1 2 3)"), keep printed
> objects in a table, and the reader can look up the object when
> presented with a tag. I've done it--it works pretty well.
>
>Doesn't this prevent any objects that are ever printed from being
>garbage collected?
Yes, but CLIM has the same problem when it saves presentations in the
output history, and this was being offered as a way to emulate this feature
of CLIM.
And the solution is the same in both cases: provide a command to clear the
record. In CLIM, when you clear the output history of a window, the
objects that were printed in the window can become garbage. Dynamic
Windows also has a command that just clears the presentation records from a
window, without actually clearing the displayed output, and I assume CLIM
inherited this feature as well.
In the above case, the table can simply be emptied, and then the objects
can be GCed.
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar