Hello,
how about wxWindows for a LISP GUI?
Read this review comparing several GUI toolkits:
http://xminc.com/linux/wxpython.html
<Quote>
wxWindows is an open source c++ toolkit that acts as a thin wrapper
around the native widget sets - GTK+, WIN32, Mac OS, Motif and others.
It has interfaces for c++, perl, python & ruby. I
Open Source Applications Foundation have decided on using wxPython
after a year of thought:
http://www.osafoundation.org/technology.htm
</Quote>
But the biggest surprise was when I discovered that there is already a
wxLisp:
http://www.pb.izm.fhg.de/lip/wxlisp/
The only problem with that is, that it doesn't seem to be open source,
yet. Maybe we could politely ask those guys to open source it, maybe
one of them is reading this article now? :))
Just some input...
I think the Lisp GUI toolkit should be as advanced as the language
itself...
On 12/4/02 2:17 PM, in article
····························@posting.google.com, "thelifter"
<·········@gmx.net> wrote:
> Hello,
>
> how about wxWindows for a LISP GUI?
The biggest problem I've had using wxWindows from Ruby for cross platform
work is that the Mac version is for the the old, dead Mac OS and the new Mac
version isn't done yet. This isn't an insurmountable problem because the
Quartz version is coming and in the mean time most of them who are
interested in Lisp probably have installed XDarwin already.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
thelifter <·········@gmx.net> wrote:
+---------------
| how about wxWindows for a LISP GUI?
...
| But the biggest surprise was when I discovered that there is already a
| wxLisp: http://www.pb.izm.fhg.de/lip/wxlisp/
|
| The only problem with that is, that it doesn't seem to be open source, yet.
+---------------
Then take a look at PLT Scheme <URL:http://www.plt-scheme.org/> and
the MrEd toolkit <URL:http://www.plt-scheme.org/software/mred/> which
is used to build the DrScheme IDE:
MrEd embeds MzScheme and extends it with a graphical user
interface (GUI) toolbox. GUI applications written with MrEd
run without modification under Windows, Mac OS, and Unix/X.
MrEd is based on wxWindows, and then extends it with a bunch of classes
built on MzScheme's single-inheritance object system. The MrEd Graphical
Toolbox Manual <URL:http://download.plt-scheme.org/doc/mred/mred.html>
has all the details.
PLT Scheme is GPL'd, though...
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
·········@gmx.net (thelifter) wrote in message news:<····························@posting.google.com>...
> Hello,
>
> how about wxWindows for a LISP GUI?
Absolutely!
In fact, I am working on wxWindows bindings right now, targetting
CLISP. This project is called, unceremoniously, ``wxcl''. It should be
retargettable to other Lisps. Because wxWindows is a C++ class
library, I'm writing some C compatible wrappers (extern "C"
functions). Also for some of the classes, I have created derived
classes so that I could hook into some virtual functions. Thus Lisp is
notified when an object is destroyed, so that it can remove it from
its hash tables.
The strategy is to try to follow the class hierarchy of wxWindows, but
using CLOS. Also some of the macros are imitated. I have things like
implement-app, and define-message-map. The message map macro just
generates CLOS methods that capture events, and contain case
statements to switch on child window ID.
Window ID's are symbols (actually objects that compare with #'eql),
rather than integers. The library maintains an interning hash table
which permanently assigns a unique integer code to each symbol, so the
wxcl user doesn't have to deal with this.
My test program can so far bring up a frame with a menu bar, a text
control and a button. Exercising the controls generates messages which
are handled in the test program's derived frame class, routed to them
by the macro-defined message maps. E.g. when you invoke File/Save, the
on-save method is invoked.
Progress is not very fast, however. I don't have a whole lot of time.
The odd evening I sit down and add another class. At some point I'm
going to focus on what I want to do with it, and just finish the
subset that I need.
I could open source this, if someone would like to patch it.
> Read this review comparing several GUI toolkits:
> http://xminc.com/linux/wxpython.html
A CLOS based wxWindow wrapper will kick wxPython into the toilet. It
will be far more true to the spirit of the C++ version too.
MFC-like message mapping screams for multiple dispatch, because the
method selection must be done on the window that is receiving the
command, and on the child control. Where the C++ has to do it using
various table hacks, because the built-in vtables are not powerful
enough, all you have to do in the Lisp is use straightforward methods.
CLOS even has support for dynamic dispatch on values that are
distinguished by EQL: integers and symbols.
I'm using finalization to clean up C++ objects, and weak hash tables
to keep track of the mapping of C++ object pointers to CLOS objects. A
few hacks are needed, because sometimes the wxWindows library expects
the caller to free an object, and sometimes it doesn't.
On the downside, wxWindows is not very Lisp friendly. It is based on
the model that you have an GUI app, and it runs for the entire
lifetime of the process image. There is no way to shut down the
wxWindows event loop, and then restart it again; you get assertions
from the underlying libraries, complaining about being reinitialized.
I don't have any easy way to interact with it via REPL; I'm using only
one thread, and that goes into the wxWindows event loop. From there,
it's just callbacks into the Lisp realm.
> But the biggest surprise was when I discovered that there is already a
> wxLisp:
> http://www.pb.izm.fhg.de/lip/wxlisp/
Ah, but the problem with this is that it's not based on a real Lisp.
It's based on the Xlisp implementation/dialect. This is not Common
Lisp. It has no real object system. wxLisp uses a simple-minded object
system based on message passing: (send <objects> <args> ...). Unless
you plan to confine your whole application to Xlisp, it just doesn't
make sense to use this. You could put the GUI into another process and
use IPC to talk S-expressions to a real Common Lisp image, but that's
a limitation.
···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
> ·········@gmx.net (thelifter) wrote in message
> news:<····························@posting.google.com>...
> > Hello,
> > how about wxWindows for a LISP GUI?
>
> Absolutely!
>
> In fact, I am working on wxWindows bindings right now,
> ......
> I could open source this, if someone would like to patch it.
I think this is always a good idea if you don't intend to sell it.
It might get some CMUCL folks interested.
> > Read this review comparing several GUI toolkits:
> > http://xminc.com/linux/wxpython.html
>
> On the downside, wxWindows is not very Lisp friendly. It is based on
> the model that you have an GUI app, and it runs for the entire
> lifetime of the process image. There is no way to shut down the
> wxWindows event loop, and then restart it again; you get assertions
> from the underlying libraries, complaining about being reinitialized.
> I don't have any easy way to interact with it via REPL; I'm using only
> one thread, and that goes into the wxWindows event loop. From there,
> it's just callbacks into the Lisp realm.
Have you seen clg, a binding of GTK+ to CLISP and CMUCL? At least
for CMUCL, the author seems to have solved the one-thread problem
somehow, so the REPL stays up while GUI apps are running.
I don't know about the CLISP version, though. Could the same
methods work for wxwindows, or is wxwindows fundamentally different?
clg looks very nice - a lot of work went into it. The GTK+ widgets are
spiffy, and there seems to be no flakiness in the connection between GTK+
and CMUCL. It is very low level, though, and it is begging to be wrapped
up in something CLOS-based.