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
Subject: Re: Someone explain (Mc)Clim to me as if I were 5 years old
Date:
Message-ID: <Ca_%g.612$qD3.35@newsfe11.lga>
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
On 2006-10-26, Ken Tilton <·········@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
Subject: Re: Someone explain (Mc)Clim to me as if I were 5 years old
Date:
Message-ID: <xQ30h.9$F62.8@newsfe09.lga>
David Lichteblau wrote:
> On 2006-10-26, Ken Tilton <·········@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
On 2006-10-26, Ken Tilton <·········@gmail.com> wrote:
> 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.
Usenet: Where others tell me what I want.
Seriously, both cells-gtk and Cello sound like something worth looking
at for someone interested in "normal" graphical user interfaces.
But perhaps I also like CLIM, now based on GTK+ and Cairo. Full command
objects, true presentations, access to many Lisp libraries, and terrific
portability (it works on my Linux), sockets not something it cares
about, but has threads, a flexi-trivial dired, and no Tcl at all.
> CG is just win32 and for all I know they have more users on
> Gtk (or not doing GUIs at all).
Allegro 8.0 has a GTK+-based CG for Linux.
d.
David Lichteblau wrote:
<SNIP>
> about, but has threads, a flexi-trivial dired, and no Tcl at all.
huh? Do you mean that McClim can utilise threads? Surely "having
threads" is a function of the Lisp implementation (and possibly the OS)
that you are using?
Cheers
Brad
"bradb" <··············@gmail.com> writes:
> huh? Do you mean that McClim can utilise threads? Surely "having
Yes, the CLIM 2 specification also defines a portable multiprocessing
interface in the CLIM-SYS interface:
B.2 Multi-processing
http://bauhh.dyndns.org:8000/clim-spec/B-2.html#_1878
> threads" is a function of the Lisp implementation (and possibly the OS)
> that you are using?
The CMUCL treading interface is modeled after CLIM-SYS.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Paolo Amoroso <·······@mclink.it> writes:
> Yes, the CLIM 2 specification also defines a portable multiprocessing
> interface in the CLIM-SYS interface:
^^^^^^^^^
I actually meant package.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
From: Ken Tilton
Subject: Re: Someone explain (Mc)Clim to me as if I were 5 years old
Date:
Message-ID: <RB80h.221$8W4.144@newsfe10.lga>
David Lichteblau wrote:
> On 2006-10-26, Ken Tilton <·········@gmail.com> wrote:
>
>>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.
>
>
> Usenet: Where others tell me what I want.
>
> Seriously, both cells-gtk and Cello sound like something worth looking
> at for someone interested in "normal" graphical user interfaces.
>
> But perhaps I also like CLIM, now based on GTK+ and Cairo.
Now yer talkin. But to get native look/feel you want Tk, not GTK+,
unless that is finally available in 2.0 form on Mac OS X. of course I
see your definition of portable means moving something between HDs on
the same Linux system, but if we are talking about Real Use and "Lisp
GUI", well, these monosystemic hacks don't even make the cut.
How about constraints? Any serious GUI has to offer GUI constraints
these days.
Finally, even McCLIM defenders admit it has a nasty learning curve. What
went wrong? Productivity tools are supposed to move us along on
projects, not stop us cold.
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
Subject: Re: Someone explain (Mc)Clim to me as if I were 5 years old
Date:
Message-ID: <87d58f1mpg.fsf@sigkill.dk>
"thetza" <······@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
Troels Henriksen wrote:
>
> 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.
This begs the question "what non-standard interfaces IS McClim good
for?" :)
I'm in the same boat as the OP, McClim looks interesting, but it is
pretty hard to twist your head around it. I'd like to read "McClim for
Dummies" if such a book existed :)
Cheers
Brad
"bradb" <··············@gmail.com> writes:
> pretty hard to twist your head around it. I'd like to read "McClim for
> Dummies" if such a book existed :)
The guided tour which comes with McCLIM (see directory Doc/Guided-Tour
in the source tree) is pretty good.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
On Thu, 26 Oct 2006 10:54:35 +0200, Troels Henriksen <·····@sigkill.dk> wrote:
>
> 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.
I have been thinking about borrowing ideas from CLIM as part of a
vague plan I have in mind for building a higher-level framework on
top of Graphic-Forms. I don't see much point in building another
Win32 backend for McCLIM when folks seem to be happy with existing
solutions. So I personally don't think CLIM is weird; rather to me
it's a source of ideas for future work.
--
Jack Unrue
From: Troels Henriksen
Subject: Re: Someone explain (Mc)Clim to me as if I were 5 years old
Date:
Message-ID: <8764e626qy.fsf@sigkill.dk>
Jack Unrue <·······@example.tld> writes:
> I don't see much point in building another Win32 backend for McCLIM
> when folks seem to be happy with existing solutions.
Actually, McCLIM doesn't currently have a Win32 backend, the only
fully functional backend we have is the CLX-based one (and work
underway on one based on GTK). A Win32 backend would be most welcome,
though I believe most McCLIM hackers are on some sort of *nix-system.
> So I personally don't think CLIM is weird; rather to me
> it's a source of ideas for future work.
I believe I heard somewhere that McCLIM itself is also a step on the
path to defining a CLIM 3.0 specification.
--
\ Troels "Athas"
/\ Henriksen
On 2006-10-26, Troels Henriksen <·····@sigkill.dk> wrote:
> Actually, McCLIM doesn't currently have a Win32 backend, the only
> fully functional backend we have is the CLX-based one (and work
> underway on one based on GTK). A Win32 backend would be most welcome,
> though I believe most McCLIM hackers are on some sort of *nix-system.
Yes, please! Jack, you need to build a clim-graphic-forms backend. It
is easy, I promise. It will make you famous. And best of all, it will
annoy the CLIM haters.
d.
On 26 Oct 2006 20:08:08 GMT, David Lichteblau <···········@lichteblau.com> wrote:
> On 2006-10-26, Troels Henriksen <·····@sigkill.dk> wrote:
> > Actually, McCLIM doesn't currently have a Win32 backend, the only
> > fully functional backend we have is the CLX-based one (and work
> > underway on one based on GTK). A Win32 backend would be most welcome,
> > though I believe most McCLIM hackers are on some sort of *nix-system.
>
> Yes, please! Jack, you need to build a clim-graphic-forms backend. It
> is easy, I promise. It will make you famous. And best of all, it will
> annoy the CLIM haters.
Heh heh. OK, that's two votes in favor, which is good enough
for me.
--
Jack Unrue
From: Ken Tilton
Subject: Re: Someone explain (Mc)Clim to me as if I were 5 years old
Date:
Message-ID: <XFd0h.45$du1.44@newsfe11.lga>
David Lichteblau wrote:
> On 2006-10-26, Troels Henriksen <·····@sigkill.dk> wrote:
>
>>Actually, McCLIM doesn't currently have a Win32 backend, the only
>>fully functional backend we have is the CLX-based one (and work
>>underway on one based on GTK). A Win32 backend would be most welcome,
>>though I believe most McCLIM hackers are on some sort of *nix-system.
>
>
> Yes, please! Jack, you need to build a clim-graphic-forms backend. It
> is easy, I promise. It will make you famous.
It certainly would be great to see McCLIM/2007/Win32. But if McCLIM has
a Gtk+ backend, why is it not already running on win32? Last excuse I
heard was that SBCL did not run on win32 (several years ago). Raising
the even more fascinating question as to how a portable GUI could end up
dependendent on a lips implementation. Anyway...
> And best of all, it will
> annoy the CLIM haters.
I am gnashing my teeth already. Congratulations, I almost had Jack ready
to add constraints to his GUI, now he is going to piss away all this
time on McCLIM instead.
So... when is the screenshot smackdown? Here is the Cells-GTk contender:
http://common-lisp.net/project/cells-gtk/screenshots.html
To whomever asked, that top shot is of an actual application.
As for Cello, what could be more beautiful than this?:
http://www.tilton-technology.com/cello-shot-06.jpg
:)
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: Christophe Rhodes
Subject: Re: Someone explain (Mc)Clim to me as if I were 5 years old
Date:
Message-ID: <sqbqnygtjl.fsf@cantab.net>
Ken Tilton <·········@gmail.com> writes:
> David Lichteblau wrote:
>> Yes, please! Jack, you need to build a clim-graphic-forms backend. It
>> is easy, I promise. It will make you famous.
>
> It certainly would be great to see McCLIM/2007/Win32. But if McCLIM
> has a Gtk+ backend, why is it not already running on win32? Last
> excuse I heard was that SBCL did not run on win32 (several years
> ago). Raising the even more fascinating question as to how a portable
> GUI could end up dependendent on a lips implementation. Anyway...
Don't confuse the issue of running on a platform and having a backend
for the "platform-native" toolkit. (The rest of this paragraph also
begs various questions; needless to say, most of the underlying
assumptions are false.)
Christophe
Troels Henriksen <·····@sigkill.dk> wrote:
>
> Jack Unrue <·······@example.tld> writes:
>
> > I don't see much point in building another Win32 backend for McCLIM
> > when folks seem to be happy with existing solutions.
>
> Actually, McCLIM doesn't currently have a Win32 backend, the only
> fully functional backend we have is the CLX-based one (and work
> underway on one based on GTK).
Yeah, sorry I should have been clearer that I was referring to
those two.
> A Win32 backend would be most welcome, though I believe most McCLIM
> hackers are on some sort of *nix-system.
I can see it being a worthwhile endeavor, and certainly a way to
get a solid understanding of what I'd be borrowing from. This is
starting to sound like a good idea, actually.
> > So I personally don't think CLIM is weird; rather to me
> > it's a source of ideas for future work.
>
> I believe I heard somewhere that McCLIM itself is also a step on the
> path to defining a CLIM 3.0 specification.
--
Jack Unrue
In article <························@i3g2000cwc.googlegroups.com>,
"thetza" <······@mm.st> 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). 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
http://www.sts.tu-harburg.de/~r.f.moeller/uims-clim/clim-intro.html
To see a similar UI in action see this movie I made
of a Symbolics Lisp Machine running a document authoring system:
http://cl-http.org:8002/mov/concordia.mov
The window system is called 'Dynamic Windows'
and was the inspiration for CLIM. CLIM was thought
as a portable, cleaned-up version written in Common Lisp.
Rainer Joswig wrote:
> In article <························@i3g2000cwc.googlegroups.com>,
> "thetza" <······@mm.st> 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). 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
>
> http://www.sts.tu-harburg.de/~r.f.moeller/uims-clim/clim-intro.html
>
Ironically enough, the links from the above page that say "clim is
alive" are dead links (-:
Brad
From: Rainer Joswig
Subject: Re: Someone explain (Mc)Clim to me as if I were 5 years old
Date:
Message-ID: <C1671770.5919A%joswig@lisp.de>
Am 27.10.2006 1:33 Uhr schrieb "bradb" unter <··············@gmail.com> in
························@f16g2000cwb.googlegroups.com:
>
> Rainer Joswig wrote:
>> In article <························@i3g2000cwc.googlegroups.com>,
>> "thetza" <······@mm.st> 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). 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
>>
>> http://www.sts.tu-harburg.de/~r.f.moeller/uims-clim/clim-intro.html
>>
> Ironically enough, the links from the above page that say "clim is
> alive" are dead links (-:
>
> Brad
>
And, did you report that to the page author?
Rainer Joswig wrote:
> Am 27.10.2006 1:33 Uhr schrieb "bradb" unter <··············@gmail.com> in
> ························@f16g2000cwb.googlegroups.com:
>
> >
> > Rainer Joswig wrote:
> >> In article <························@i3g2000cwc.googlegroups.com>,
> >> "thetza" <······@mm.st> 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). 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
> >>
> >> http://www.sts.tu-harburg.de/~r.f.moeller/uims-clim/clim-intro.html
> >>
> > Ironically enough, the links from the above page that say "clim is
> > alive" are dead links (-:
> >
> > Brad
> >
>
> And, did you report that to the page author?
I hadn't. But when I did, his email link is also broken.
Brad
In article <························@h48g2000cwc.googlegroups.com>,
"bradb" <··············@gmail.com> wrote:
> Rainer Joswig wrote:
> > Am 27.10.2006 1:33 Uhr schrieb "bradb" unter <··············@gmail.com> in
> > ························@f16g2000cwb.googlegroups.com:
> >
> > >
> > > Rainer Joswig wrote:
> > >> In article <························@i3g2000cwc.googlegroups.com>,
> > >> "thetza" <······@mm.st> 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). 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
> > >>
> > >> http://www.sts.tu-harburg.de/~r.f.moeller/uims-clim/clim-intro.html
> > >>
> > > Ironically enough, the links from the above page that say "clim is
> > > alive" are dead links (-:
> > >
> > > Brad
> > >
> >
> > And, did you report that to the page author?
>
> I hadn't. But when I did, his email link is also broken.
>
> Brad
r.f.moeller -at- tuhh.de
From: Robert Strandh
Subject: Re: Someone explain (Mc)Clim to me as if I were 5 years old
Date:
Message-ID: <6wodrywdsw.fsf@serveur5.labri.fr>
"thetza" <······@mm.st> writes:
> 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.
This is the way most programs using traditional GUI libraries are
structured.
But that structure is an unfortunate side-effect of the low level of
those traditional GUI libraries. By having to handle events, you no
longer have access to execution contexts such as the stack, and you
have to manage all kinds of contexts yourself, or else you end up with
applications that have a very rudimentary interaction policy.
> 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?
CLIM turns the structure of traditional GUI libraries inside-out, and
makes it both possible and normal so use interaction methods that are
common in non-GUI based programs, i.e. where the program logic has the
initiative, and you use reads and writes to accomplish the
interaction.
CLIM has a "command loop" that is at a higher level than an event loop
and that:
* acquires a command. You might satisfy this demand by clicking on
a menu item, by typing the name of a command, by hitting some kind
of keystroke, by pressing a button, or by pressing some visible
object with a command associated with it ;
* acquires the arguments required by that command. These arguments
are often associated with a "presentation type", and visible
objects of the right presentation type can be clicked on to
satisfy this demand. You can also type a textual representation
of the argument, using completion, or you can use a context menu ;
* calls the command on its arguments, usually resulting in some
significant modification of the "model", i.e. the data structure
representing your application logic ;
* calls a redisplay routine (which might use incremental redisplay)
to update your views of the model.
Writing a CLIM application therefore consists of:
* writing CLIM commands that modify the model independently of how
those commands are invoked, and which may take application objects
as arguments ;
* writing display routines that turns the model (and possibly some
"view" object) into a collection of visible representations
(having presentation types) of application objects ;
* writing completion routines that allows you to type in application
objects (of a certain presentation type) using completions ;
* independently deciding how commands are to be invoked (menus,
buttons, presentations, textual commands, etc).
By using CLIM as a mediator of command invocation and argument
acquisition, you can obtain some very modular code indeed.
But there is more. CLIM is a well-documented and very rich collection
of internal protocols, and programmers can add, modify, or replace
components of CLIM by respecting those protocols, in particular the
programmer can:
* use CLOS :before, :after, and :around methods on documented CLIM
generic functions to modify the behavior of standard CLIM in
interesting ways ;
* add new types of panes and gadgets ;
* modify the way presentation types are displayed, or the way they
are sensitive to mouse gestures ;
* add specialized output records for particular application needs ;
* replace the standard command loop ;
* etc, etc, etc.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------