What is the difference between LispView and CLIM?
Does LispView offer any functionality beyond Dynamic Windows (Symbolics)
or CLIM? Is it any simpler? How is portability?
Thank you,
Leslie A. Walko
······@bellcore.com
From: Jeff Dalton
Subject: Re: LispView vs CLIM
Date:
Message-ID: <5631@skye.ed.ac.uk>
In article <······················@walter.bellcore.com> <······@breeze.bellcore.com> writes:
>What is the difference between LispView and CLIM?
Well, for one thing LispView is available for ftp on the net and,
so far as I can tell, CLIM isn't. This makes all the difference
to me.
|> >What is the difference between LispView and CLIM?
|>
|> Well, for one thing LispView is available for ftp on the net and,
|> so far as I can tell, CLIM isn't. This makes all the difference
|> to me.
There is another difference: LispView works only with Lucid while CLIM
works with Allegro, Harlequin, Mac CL and Symbolics. In other words, CLIM
is a "de facto" standard.
--
Emmanuel Baechler.
Laboratoire d'Intelligence Artificielle
Ecole Polytechnique Federale de Lausanne
MA-Ecublens
CH-1015 Lausanne Switzerland
Tel.: ++41-21-693-2732
e-mail: ········@liasun6.epfl.ch
Standard Disclaimer
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: Jeff Palmucci
Subject: Re: LispView vs CLIM
Date:
Message-ID: <67380@bbn.BBN.COM>
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
Thank you for all the replies. I found them quite helpful in choosing
between CLIM and LispView.
Leslie Walko
······@bellcore.com
From: Jeff Dalton
Subject: Re: LispView vs CLIM
Date:
Message-ID: <5647@skye.ed.ac.uk>
In article <····@disuns2.epfl.ch> ········@liasun3.epfl.ch (Emmanuel Baechler) writes:
>
>|> >What is the difference between LispView and CLIM?
>|>
>|> Well, for one thing LispView is available for ftp on the net and,
>|> so far as I can tell, CLIM isn't. This makes all the difference
>|> to me.
>
> There is another difference: LispView works only with Lucid while CLIM
>works with Allegro, Harlequin, Mac CL and Symbolics. In other words, CLIM
>is a "de facto" standard.
_At present_ LispView works only with Lucid.
I do not agree that CLIM counts as a de facto standard. I use
about 4 or 5 different Common Lisps, including Lucid and Allegro.
I don't have access to any implementation of CLIM. Moreover,
before I regard something as a standard for Common Lisp I'll
want to be using it in KCL and CMU CL as well the commercial
implementations.
CLX might be an example of a de facto standard, but not CLIM.
Or at least not yet.