Prev: What does "protocol" mean in CLOS terms?
Next: SBCL fatal error: fake_foreign_call fell through
From: thetza on 25 Oct 2006 21:04
I've managed to get McClim installed and running on debian with cmucl
and slime, been playing with the examples, but I can't seem to wrap my
head around it. It might be b/c I haven't found a good tutorial, but I
think it has more to do with the preconceptions about what a GUI
toolkit is and how GUI programs are structured (I've been developing
GUI's with wxWindows, GTK, and Tk). So here are my preconceptions:

To me, a GUI toolkit at the least:
a. Handles all the low-level interaction with underlying graphics
engine (xlib, etc).
b. Has a collection of 'widgets', preferably arranged in an OO fashion
so you can make your own widgets from existing ones.
c. Has some sort of event system.

And to me, a GUI program is structured as follows:
a. You create instances of different widget with various options,
b. you lay them out in a geometry manager,
c. you bind events to your widgets, and
d. you start your event loop.

Can someone compare and contrast McClim to the more "traditional" gui
toolkits, both in terms of its scope/purpose/goals and how McClim
applications are to be structured?

thanks,
Thetza

From: Ken Tilton on 26 Oct 2006 04:17


thetza wrote:
> I've managed to get McClim installed and running on debian with cmucl
> and slime, been playing with the examples, but I can't seem to wrap my
> head around it. It might be b/c I haven't found a good tutorial, but I
> think it has more to do with the preconceptions about what a GUI
> toolkit is and how GUI programs are structured (I've been developing
> GUI's with wxWindows, GTK, and Tk).

Pardon a non-responsive response, but why do you want to use McClim or
any form of Clim? Most of us are using Tk, Gtk, wxWindows, or
implementation-specific GUIS that work just like the ones you are used
to. Clim never really caught on.

kt

--
Cells: http://common-lisp.net/project/cells/

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Troels Henriksen on 26 Oct 2006 04:54
"thetza" <thetza(a)mm.st> writes:

> It might be b/c I haven't found a good tutorial, but I
> think it has more to do with the preconceptions about what a GUI
> toolkit is and how GUI programs are structured (I've been developing
> GUI's with wxWindows, GTK, and Tk).

You're right, it's because CLIM is very weird compared to mainstream
GUIs, sort of like CL is different from mainstream languages. We are a
bunch of people that really like the CLIM UI paradigm, but you should
not expect to be able to create "standard" user interfaces with it.

> a. Handles all the low-level interaction with underlying graphics
> engine (xlib, etc).

CLIM does this.

> b. Has a collection of 'widgets', preferably arranged in an OO fashion
> so you can make your own widgets from existing ones.

CLIM has this, but there are not very many widgets (called "gadgets"
in CLIM-speak) in McCLIM. Also, their interface is a bit limited, and,
at least the CLIM applications I know of, do not use very many
gadgets.

> c. Has some sort of event system.

There is an event system, but unless you're writing gadgets or other
relatively low-level stuff, you're not meant to use it. One of the
hardest things to wrap my head around when I learned CLIM was that it
is not really event-based - instead, CLIM takes care of reading
gestures from the user and looks up the corresponding commands in
command tables that you have defined for your application.

> a. You create instances of different widget with various options,

You need to create the elements of your application, of course - but
you generally have fewer discrete UI elements in CLIM applications
than in normal applications, though my view may be colored by the fact
that I have never tried the commercial CLIM implementations, nor a
"real" commercial CLIM application.

> b. you lay them out in a geometry manager,

You do this in CLIM as well.

> c. you bind events to your widgets, and

You do this in CLIM as well.

> d. you start your event loop.

You do this in CLIM as well.

(Though all of these things are generally done via the
`define-application-frame' macro)

> Can someone compare and contrast McClim to the more "traditional" gui
> toolkits, both in terms of its scope/purpose/goals and how McClim
> applications are to be structured?

I recommend that you take a look at the Examples directory of McCLIM,
as well as a look at the code for Beirc
(http://common-lisp.net/project/beirc/), a typical free CLIM
application.

--
\ Troels "Athas"
/\ Henriksen
From: David Lichteblau on 26 Oct 2006 06:27
On 2006-10-26, Ken Tilton <kentilton(a)gmail.com> wrote:
> Pardon a non-responsive response, but why do you want to use McClim or
> any form of Clim?

Perhaps because CLIM implements some interesting concepts, and with the
prominent exception of normal widgets ("gadgets") is rather complete.

> Most of us are using Tk, Gtk, wxWindows, or
> implementation-specific GUIS that work just like the ones you are used
> to.

Using or implementing?

There are certainly lots of Lisp programmers _implementing_ such GUI
toolkits in Lisp (LTK, various GTK+ bindings, Graphic Forms, cells-gtk).

How many real applications based on those libraries are there?

(Oh, I know, closed-source commercial software using Franz CG and
LispWorks CAPI that nobody has ever heard of. Right.)

> Clim never really caught on.

Perhaps not until McCLIM came along. Now there are various non-trivial
applications using CLIM, e.g. Climacs, Beirc, Gsharp, and of course
Closure. Neither of which is complete and perfect, but all of them are
basically usable and certainly more than just a toy example.


d.
From: Ken Tilton on 26 Oct 2006 10:43


David Lichteblau wrote:
> On 2006-10-26, Ken Tilton <kentilton(a)gmail.com> wrote:
>
>>Pardon a non-responsive response, but why do you want to use McClim or
>>any form of Clim?
>
>
> Perhaps because CLIM implements some interesting concepts, and with the
> prominent exception of normal widgets ("gadgets") is rather complete.
>
>
>> Most of us are using Tk, Gtk, wxWindows, or
>>implementation-specific GUIS that work just like the ones you are used
>>to.
>
>
> Using or implementing?

Cells-Gtk, LTk, and Celtk/Cello (the line is blurry now) are all being
used, tho I confess my Cells-Gtk assessment is based on the fact that it
seems to be actively supported.

>
> There are certainly lots of Lisp programmers _implementing_ such GUI
> toolkits in Lisp (LTK, various GTK+ bindings, Graphic Forms, cells-gtk).

The one you want is Cello, now based on Tk/Tcl and OpenGL. Full event
stream, true callbacks, access to the many Tk/Tcl libs, and terrific
portability (of more than just the native look/feel GUI -- sockets,
threads, file manager services, the whole Tcl language really.

And is being used heads down in development of something I hope to
release in 3-6 months, so very active and very real-world.

>
> How many real applications based on those libraries are there?

Not fair. Ron had it wrong. Lisp programmers are /too/ social, spend all
their time chatting on c.l.l or closing pubs, never actually write any code.

>
> (Oh, I know, closed-source commercial software using Franz CG and
> LispWorks CAPI that nobody has ever heard of. Right.)

What do you mean by "Right."? You do not believe it? :) And why does it
bother you that you have never heard of them? The testimonials from CAPI
users make clear they are using that library in anger, at least, and I
do not think Franz suppports itself without people using --- well,
whaddoIknow? CG is just win32 and for all I know they have more users on
Gtk (or not doing GUIs at all).

>
>
>> Clim never really caught on.
>
>
> Perhaps not until McCLIM came along. Now there are various non-trivial
> applications using CLIM, e.g. Climacs, Beirc, Gsharp, and of course
> Closure. Neither of which is complete and perfect, but all of them are
> basically usable and certainly more than just a toy example.

I heard LW was deprecating CLIM, and I think Franz is as well. My take
is that CLIM /tried/ to be this incredibly better presentation manager
the way CLOS is incredible at OO, but was badly designed from the
programmer's perspective -- too damn hard to learn and use, and
unnecessarily so. That last bit is unforgivable.

Meanwhile, look at this thread. Programmers coming to Lisp know how to
put up a GUI in any number of languages, then they run into CLIM. Ooops.
They also know a GUI is built up from widgets, and you concede CLIM
don't play that. Oooops. I am not saying Lisp should not do better than
other languages, but I am saying CLIM went in search of better along the
wrong axes.

CLIM was a bold leap and I love bold leaps, but this one did not pan out
and the energy going into McCLIM is just a mistake.

kt

--
Cells: http://common-lisp.net/project/cells/

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: What does "protocol" mean in CLOS terms?
Next: SBCL fatal error: fake_foreign_call fell through