OK, so what do people want in their Lisp GUI library?
I've been playing with CLIM lately. (And since the fiance is going back to
work next week, I'll have more time to work on it!) There are some aspects of
it I like and some I don't. I like presentation types. I think the appearance
of CLIM apps are ugly, even by my utilitarian viewpoint. (I like the look of
Xaw!) CLIM is also big and complicated!
I don't care for the thin Lisp veneer over a C library versions of GUIs
either. Writing C in Lisp defeats the purpose of using Lisp in the first
place.
I'd prefer it to be CLOS based. In particular, I like having all of the
graphic functions be generic functions specialized on the required arguement
of an instance of a drawable, aka I want
(defmethod draw-line ((win my-window-class) x0 y0 x1 y1
&key &allow-other-keys &rest options)
...)
It would be nice if it were portable across the major hardware platforms out
their ie. X, Windoze, and possibly Mac. I'm not concerned that it run on every
concievable platform. (I don't expect GUI apps on my Linux box to run
unchanged on a PalmPilot.)
I'd like it to be freely available, including source.
Others?
Mike McDonald
·······@mikemac.com
In article <··············@rtp.ericsson.se>,
Raymond Toy <···@rtp.ericsson.se> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
>> OK, so what do people want in their Lisp GUI library?
>
> Something that's easy to use and comes with examples and
> documentation. Garnet does this more or less.
>
> [snip]
>
>>
>> I'd prefer it to be CLOS based. In particular, I like having all of the
>> graphic functions be generic functions specialized on the required arguement
>> of an instance of a drawable, aka I want
>
> The only free one that I know of is CLUE/CLIO and XIT.
>
> CLUE is, I think, Xt in Lisp. CLIO is an openlook-style using CLUE.
> I've used these only a little.
>
> XIT is another system using CLOS. Got it to compile and run a few
> demos but that's the limit of my experience.
>
> Of all of the free ones, I like Garnet the best because there are lots
> of examples and lots of documentation. But it's not CLOS.
>
> Ray
My question was about what you wanted, not what's already available. What's
the programming model? What look and feel? ...
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
>
> My question was about what you wanted, not what's already available. What's
> the programming model? What look and feel? ...
Sorry, I misunderstood.
To your question, I want something that's easy to use to do the simple
things like menus, buttons, etc. Despite all of its faults, Tk/Tcl is
fairly easy to use to get a reasonably nice and functional GUI. STk
is pretty good here.
CLOS is nice but not necessary.
For look and feel, I guess motif. Anything but the goofy Windows
scrollbar behavior.
Ray
Raymond Toy wrote:
> ...
> To your question, I want something that's easy to use to do the simple
> things like menus, buttons, etc. Despite all of its faults, Tk/Tcl is
> fairly easy to use to get a reasonably nice and functional GUI. STk
> is pretty good here.
>
> CLOS is nice but not necessary.
I think STk's object system is very much like CLOS (not sure though)
> ...
--
Hartmann Schaffer
Guelph, Ontario, Canada
········@netcom.ca (hs)
That sounds overall like a pretty good thing(tm). I wonder if
there isn't already a cheap way to do that kind of thing. Swing has
some pretty nifty features. What if a lisp GUI application could kickstart
a java VM and pass windowing messages to it? The VM would behave like an
X server.
What if the system could parse java bytecodes? It could then
import swing wholesale and use it as a windowing system.
I know this might not be ideal, but I'm trying to think of
bang-for-the-buck here. It might same time to borrow and steal
rather than write from scratch.
dave
Mike McDonald wrote in message ...
> OK, so what do people want in their Lisp GUI library?
>
If you haven't already done so, have a look at the Squeak smalltalk system.
A CLOS version of that (esp the Morphic interface) would meet most of my
needs and could be built on a very low substrate as they have done.
In article <······················@news.teleport.com>,
Mike McDonald <·······@mikemac.com> wrote:
> OK, so what do people want in their Lisp GUI library?
>
One thing I'm planning to do fairly soon is to interface Tk with
Macintosh Common Lisp (3.9 or better). I haven't figured out any
of the details yet.
Tk is generally available, open source, freely distributable, and
works on X, Windows, and the Mac (with more-or-less native look and
feel). While I have no love for Tcl, I don't see that I need to
do a whole lot with it (perhaps generate it on the fly).
If I were to make it into a full-fledged GUI, it seems to me that
there would be two parts.
First, there would be the system-specific part which would be unique
to each version of Lisp (note that PPC and 68K-based MCLs count as
different versions here). This would consist of functions that would
take low-level commands, and generate the Tcl needed to create the
Tk objects.
This had better have a consistent interface, for the second to work.
The interface can be clumsy, but it must be complete, consistent, and
transportable to all platforms Tcl/Tk runs on (basically, X, Windows,
Mac). Ideally, the implementations would be efficient.
Second, there would be a platform-independent GUI framework based
on CLOS. (Yeah, performance issues. GUIs don't have to be fast,
except for arcade games, which you wouldn't use a cross-platform
interface with interpretive layers anyway.) Actually, knowing
the Lisp community, there'd be several frameworks. Fine.
One problem I have is that there is literally nothing available
that I want to use. CLIM is proprietary and usually expensive;
further, last I saw, the MCL version was in alpha status. (I figure
it's alpha when they tell you which of the standard demos will
crash Lisp.) Garnet doesn't do Windows, uses its own object
system, and is a resource hog. (Fortunately, memory is cheap,
and MCL with Garnet seemed fairly happy in a 25M partition.)
Most of the free toolkits are X-based, and I don't *want* to
have to do a freeware port of X to the Macintosh.
All I really want is world domin^H^H^H^H^H^H^H^H^H^H^Hto sit
in my study with my G3 Mac and my Macintosh Common Lisp and write
nicely portable stuff using CLOS and other neat stuff.
--
David H. Thornley | These opinions are mine. I
·····@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly. O-
In article <·····················@ptah.visi.com>, ········@visi.com (David
Thornley) wrote:
> further, last I saw, the MCL version was in alpha status. (I figure
> it's alpha when they tell you which of the standard demos will
> crash Lisp.)
Isn't it already beta?
> All I really want is world domin^H^H^H^H^H^H^H^H^H^H^Hto sit
> in my study with my G3 Mac and my Macintosh Common Lisp and write
> nicely portable stuff using CLOS and other neat stuff.
Sounds good. I'd not hold my breath for another library.
>>>>> "DT" == David Thornley <········@visi.com> writes:
DT> One thing I'm planning to do fairly soon is to interface Tk with
DT> Macintosh Common Lisp (3.9 or better). I haven't figured out any
DT> of the details yet.
DT>
DT> Tk is generally available, open source, freely distributable, and
DT> works on X, Windows, and the Mac (with more-or-less native look and
DT> feel). While I have no love for Tcl, I don't see that I need to
DT> do a whole lot with it (perhaps generate it on the fly).
Rather than dirtying your hands with Tcl, you might be interested in
pTk[1], an externally callable adaptation of the Tk toolkit. While it
currently works with Perl, the idea of the project is to make Tk
accessible from languages other than Tcl.
[1] http://w4.lns.cornell.edu/~pvhp/ptk/qna1.html
--
Eric Marsden
emarsden @ mail.dotcom.fr
It's elephants all the way down
Eric Marsden <········@mail.dotcom.fr> writes:
>
> Rather than dirtying your hands with Tcl, you might be interested in
> pTk[1], an externally callable adaptation of the Tk toolkit. While it
> currently works with Perl, the idea of the project is to make Tk
> accessible from languages other than Tcl.
>
That is a good thing. IMHO, I believe that without Tk, few people
would have bothered with Tcl at all.
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 80 79 23, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
From: Howard R. Stearns
Subject: CL-Tk? (was: Ideal GUI toolkit in Lisp??)
Date:
Message-ID: <35AB8BB5.4B0D393F@elwood.com>
Is there any such thing as CL-Tk?
i.e. a port of STk to Common Lisp, built on the usual
platforms-specific FFI macros.
Would such a thing make sense?
Eric Marsden wrote:
>
> >>>>> "DT" == David Thornley <········@visi.com> writes:
>
> DT> One thing I'm planning to do fairly soon is to interface Tk with
> DT> Macintosh Common Lisp (3.9 or better). I haven't figured out any
> DT> of the details yet.
> DT>
> DT> Tk is generally available, open source, freely distributable, and
> DT> works on X, Windows, and the Mac (with more-or-less native look and
> DT> feel). While I have no love for Tcl, I don't see that I need to
> DT> do a whole lot with it (perhaps generate it on the fly).
>
> Rather than dirtying your hands with Tcl, you might be interested in
> pTk[1], an externally callable adaptation of the Tk toolkit. While it
> currently works with Perl, the idea of the project is to make Tk
> accessible from languages other than Tcl.
>
> [1] http://w4.lns.cornell.edu/~pvhp/ptk/qna1.html
>
> --
> Eric Marsden
> emarsden @ mail.dotcom.fr
> It's elephants all the way down
Mike McDonald <·······@mikemac.com> wrote:
> OK, so what do people want in their Lisp GUI library?
I am not sure what the word "library" means in this context. In no
order, few chaotic ideas on my wishlist:
- A quality look&feel, a finesse which is of the first order.
- A GUI tool/environment with which to build interfaces, such that the
tool can take over Lisp (as S-graphics was to ZetaLisp for animation
designers) and make Lisp environments useful to non-Lisp users. Ie. a
GUI to build GUIs, which are represented internally in Lisp.
- A rich and fast clipping model
- A way to carry the drawing context about efficiently, without passing
mountains of function/method arguments.
- And a system which encourages the development and sharing of GUI
components amongst the Lisp community as a whole. Inherently
encouraging this - perhaps a "plug-in" architecture. Where the core
system is solid and reliable, but the integration of flakey/sexy/wierd
additions is encouraged and managable.
- Intuitive, tracable and no-lockup error handling
- The concept of ink (a la CLIM) seems neat, easy, powerful.
- Presentations as an extension to CLOS.
- A huge toolbox of drawing tools, where style components are mixed in
incrementally and in a continuous way (rather than having to pick
different primitives (as in draw-line v draw-dashed-line, rather
draw-line in line dashing context))
- Fast affine transformation
- Non-conser (no runtime garbage)
- Not too bound by rectalinear thinking
- Screamingly fast overall (especially at handling rich text).
- Moderate memory/binary requirements, at least so core can be
shrinkwrapped.
- Dead easy double buffering, incremental redisplay, drag&drop, ...
- Hyperlinked documentation with rich cross indexing, which helps those
who are lost in Lisp, graphics in general, this tool in particular, ...
- A window management system with handlers that beginners can get their
heads round.
- Meta-styles, as in 3d look, such that widgets, windows, etc. all is
coordinated as one user experience.
- Colormap toolbox (including standard maps and cycling)
- A plethora of analog gadgets (for app deployment, and in GUI builder
itself).
- Object persistance woven in
- An extensible architecture
- Sources
- Accessible to all (free or nominal price)
- A split personality for portability, ie. a common core substrate, then
one part totally portable (lowest common denominator), and another part
which is OS-centric.
- A tool with a future
- Owership/stewardship which is accessible and responsive.
- A tool which will allow and encourage Lisp engineers to make their
work visible, usable, useful, attractive, worth investing in.
-
The lack of this tool sometimes feels like the worst thing about the
Lisp culture.
Does such a toolkit exist for *any* language/development environment? If so,
I want it.
Bob Manjoney
McHugh Software International
P2 wrote in message <······················@ppp359.enterprise.net>...
>
>> OK, so what do people want in their Lisp GUI library?
>
>I am not sure what the word "library" means in this context. In no
>order, few chaotic ideas on my wishlist:
>
> (.....long list of desirable features deleted.....)
From: Christopher Browne
Subject: Re: Ideal GUI toolkit in Lisp??
Date:
Message-ID: <77eci9$5qk$1@blue.hex.net>
On Sat, 11 Jul 1998 13:53:37 GMT, Bob Manjoney <···@acm.org> wrote:
>P2 wrote in message <······················@ppp359.enterprise.net>...
>>
>>> OK, so what do people want in their Lisp GUI library?
>>
>>I am not sure what the word "library" means in this context. In no
>>order, few chaotic ideas on my wishlist:
>>
>> (.....long list of desirable features deleted.....)
>
>Does such a toolkit exist for *any* language/development environment? If so,
>I want it.
I'd characterize it as:
"A system that does not impose structure on the user/programmer, but
nonetheless somehow *provides* a great deal of structure *for*
user/programmer."
Unfortunately, you can't get the structure you need to implement a
system without there being a need to force structure onto the system.
As a result, you get the situation where, for instance, it is easy, with
a tool like MS Access, to build certain simple sorts of applications.
This comes at two costs:
a) The applications don't scale, and
b) Since a great deal of structure is forced on you, if you go along
with the structure, you get some sorts of results easily (e.g. - certain
sorts of simple form-based apps), but go beyond that with *great*
difficulty.
No structure --> no guidance --> applications have no coherent set of
common abstractions.
X gets flamed heavily for this; it provides some basic graphical
operators, but has no inherent "toolkit." You get a powerful tool on top
of which you might implement a powerful GUI, but it provides no actual
GUI.
Lots of structure --> excessive guidance --> there are some common
abstractions that get *forced* onto apps, and you go in other directions
at your peril.
Thus, while MS Access may be (arguably) acceptable for building a
database/form-oriented application, it provides little of value to
someone building a program to do visual manipulations of network flow
problems. The problem structure doesn't match the tool's structure.
The "universal GUI toolkit" seems to me to be a Holy Grail that won't be
found. If it's simple enough to be comprehended, then it doesn't
contain enough abstractions to make it easy to support all the system
structures that are needed.
--
"Linux: the operating system with a CLUE... Command Line User
Environment". (seen in a posting in comp.software.testing)
········@ntlug.org- <http://www.hex.net/~cbbrowne/lsf.html>
Hi,
This particular thread originated with a post from Mike McDonald, about
half a year ago. Dejanews gave me 17 follow-ups. Mike then commented:
" My question was about what you wanted, not what's already available.
What's the programming model? What look and feel? ..."
So put I myself as the End User Program Developer. I use would probably
use some packages, one of which is the GUI kit. Other toolkits could be
modelling (eg: solids), filing and archiving, analysis, etc.
My application is probably a combination of these tools. They are used
to create the abstract or "problem" model, the viewed model, and the
interaction model. The abstract model will probably not map directly to
a viewing model that is appropriate for the task at hand.
Most GUI toolkits offer esoteric buttons, gadgets and widgets, but only
a very limited set of 2D-geometry primitives. The kits support the
simple command loop: select action(button) - select application object -
call a procedure. Therefore, most programs are not really context
sensitive. (I would expect Autocad to excel at this, having Autolisp
around, but the number of uncomprehensible pushbuttons and data-entry
fields is staggering.)
One challenge for the GUI toolkit designer is to design and present
usable mechanisms that promote context sensitivity. Another is to
provide a much richer set of geometry primitives, whether objects with
visual attributes, or functions to be called.
Christopher Browne wrote:
>
> Unfortunately, you can't get the structure you need to implement a
> system without there being a need to force structure onto the system.
>
> Lots of structure --> excessive guidance --> there are some common
> abstractions that get *forced* onto apps, and you go in other directions
> at your peril.
This is even worse than lack of structure, which can usually be added.
> ...Access .. it provides little of value to
> someone building a program to do visual manipulations of network flow
> problems. The problem structure doesn't match the tool's structure.
Yes indeed.
> The "universal GUI toolkit" seems to me to be a Holy Grail that won't be
> found. If it's simple enough to be comprehended, then it doesn't
> contain enough abstractions to make it easy to support all the system
> structures that are needed.
Yes, although "universal" is open to interpretation, and so is "GUI
toolkit". Imagine a solid modeller, capable of building assemblies,
supplemented with powerful text functions, and with visual attributes
and mouse sensitivity built in. Wouldn't that be a nice lowest level to
have in the GUI kit?
I would appreciate a new GUI kit that
- Has a rich set of primitives, such as those in OpenGL.
- Uses CLOS where appropriate.
- Provides structure building tools, rather than structures.
- Good pilot examples, that have been reviewed by application
builders.
The ones you find in most kits are too simplistic, and the
programming
approach is often wrong.
/Lars Lundback
From: Christopher Browne
Subject: Re: Ideal GUI toolkit in Lisp??
Date:
Message-ID: <77gtp4$ahv$1@blue.hex.net>
On Sat, 11 Jul 1998 13:53:37 GMT, Bob Manjoney <···@acm.org> wrote:
>P2 wrote in message <······················@ppp359.enterprise.net>...
>>
>>> OK, so what do people want in their Lisp GUI library?
>>
>>I am not sure what the word "library" means in this context. In no
>>order, few chaotic ideas on my wishlist:
>>
>> (.....long list of desirable features deleted.....)
>
>Does such a toolkit exist for *any* language/development environment? If so,
>I want it.
I'd characterize it as:
"A system that does not impose structure on the user/programmer, but
nonetheless somehow *provides* a great deal of structure *for*
user/programmer."
Unfortunately, you can't get the structure you need to implement a
system without there being a need to force structure onto the system.
As a result, you get the situation where, for instance, it is easy, with
a tool like MS Access, to build certain simple sorts of applications.
This comes at two costs:
a) The applications don't scale, and
b) Since a great deal of structure is forced on you, if you go along
with the structure, you get some sorts of results easily (e.g. - certain
sorts of simple form-based apps), but go beyond that with *great*
difficulty.
No structure --> no guidance --> applications have no coherent set of
common abstractions.
X gets flamed heavily for this; it provides some basic graphical
operators, but has no inherent "toolkit." You get a powerful tool on top
of which you might implement a powerful GUI, but it provides no actual
GUI.
Lots of structure --> excessive guidance --> there are some common
abstractions that get *forced* onto apps, and you go in other directions
at your peril.
Thus, while MS Access may be (arguably) acceptable for building a
database/form-oriented application, it provides little of value to
someone building a program to do visual manipulations of network flow
problems. The problem structure doesn't match the tool's structure.
The "universal GUI toolkit" seems to me to be a Holy Grail that won't be
found. If it's simple enough to be comprehended, then it doesn't
contain enough abstractions to make it easy to support all the system
structures that are needed.
--
"Linux: the operating system with a CLUE... Command Line User
Environment". (seen in a posting in comp.software.testing)
········@ntlug.org- <http://www.hex.net/~cbbrowne/lsf.html>