Hi,

As a casual user of CLIM I find the most frustrating problem is just downloading all the proper pieces and placing them where they can be used. If someone would take the time to create a pdf of step by step instructions on where to go, what to download, and the required destinations it would be most helpful. I know some things like this exist but many seem out of date and don’t really work that well.

I currently use SBCL on a Fedora 12 machine.

Regards Bill Sauer

From: Mariano Montone Sent: Saturday, July 07, 2012 5:57 PM To: Christophe Rhodes Cc: mcclim-devel@common-lisp.net Subject: Re: [mcclim-devel] Why is CLIM dead

Thanks Christophe

That CLIM needs some human power and is not deeply flawed is good news to me. I can work on it and use it knowing that my work is not completely meaningless from the start.

Cheers,

Mariano

On Sat, Jul 7, 2012 at 5:53 PM, Christophe Rhodes csr21@cantab.net wrote:

Mariano Montone marianomontone@gmail.com writes:

So I was wondering why CLIM is dead. It looks like it doesn't have any activity at all. And I think it is a pity, because when I first looked at Listener/Climacs/Debugger/Inspector stuff, I thought it would be a very nice replacement for SLIME, for instance. I'm SLIME user, but I think there's lot of room for improvements in the Lisp tools area, and the CLIM tools + usability improvements + possibilities to extend the tools very easily sounds very good to me.

Well, one argument is that things don't start out equal. Yes, the Listener, Climacs, Debugger and Inspector are pretty good, but they have to compete with other tools out there, not only for functionality but also for maintenance time. Put bluntly, CLIM is sleeping (maybe not dead, because interesting ideas never die :) because there was a lack of person power to keep it awake. I agree that there's a lot of potential in the tools, but there's a lot of potential in all sorts of things and only a limited amount of time to spend developing that potential.

Does anyone know why CLIM is not used anymore? Does it have any very bad design decisions? I'm not really sure about output recording/redisplay, etc (I haven't seen theme elsewhere, as if that could be automatically handled in general). Don't know about composability and layout yet (I'm still struggling a bit with that now). And I also see some bugs, like some refreshing problems when scrolling, but bugs should be fixable.

It's not got terrible design decisions: there are a couple of problems in some layers of the stack, but nothing that couldn't be worked around. Output recording and incremental redisplay are brave ideas, output recording somewhat more salvageable than incremental redisplay, but they don't cost too much if you don't use them. I don't think there's anything fundamentally wrong with CLIM, or fundamentally better in other toolkits: it's just that the pool of talent and energy to perform the pretty thankless task of making it all work to the extent of its potential seems currently unavailable.

What would it take? Money, or graduate students, I think.

Cheers,

Christophe

-------------------------------------------------------------------------------- _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel

Thank you, I will try that.

Bill

From: Mariano Montone Sent: Monday, July 09, 2012 9:15 AM To: Bill Sauer Cc: Christophe Rhodes ; mcclim-devel@common-lisp.net Subject: Re: [mcclim-devel] Why is CLIM dead

On Mon, Jul 9, 2012 at 11:28 AM, Bill Sauer bill@volersystems.com wrote:

Hi,

As a casual user of CLIM I find the most frustrating problem is just downloading all the proper pieces and placing them where they can be used. If someone would take the time to create a pdf of step by step instructions on where to go, what to download, and the required destinations it would be most helpful. I know some things like this exist but many seem out of date and don’t really work that well.

I currently use SBCL on a Fedora 12 machine.

Regards Bill Sauer

Bill, in my case using Quicklisp works with no problems. I'm on an Ubuntu Machine and SBCL.

First install quicklisp, if you haven't already: http://www.quicklisp.org.

Then evaluate:

(ql:quickload :mcclim)

For better looking fonts, evaluate:

(ql:quickload :mcclim-truetype)

To run the examples:

(ql:quickload :clim-examples) and then: (clim-demo::demodemo)

Cheers,

Mariano

On Mon, Jul 9, 2012 at 12:50 PM, Bruce Seely seelybs@gmail.com wrote:

Hi,

I am trying Mariano's approach below, and run into a problem while loading McClim. It looks like the package XLIB cannot be found, while loading the image package. Does anyone have an idea of how to proceed?

Thanks for your help, Bruce

...

At this point anerror occurs:

Package "XLIB" not found. [file position = 2914] [Condition of type READER-ERROR]

Restarts: 0: [NIL] retry the compilation of /Users/bseely/site-lisp/dists/quicklisp/software/mcclim-20120520-cvs/Backends/CLX/image.lisp 1: [NIL] continue compiling /Users/bseely/site-lisp/dists/quicklisp/software/mcclim-20120520-cvs/Backends/CLX/image.lisp but generate no output file 2: [RETRY] Retry compiling #<CL-SOURCE-FILE "clim-clx" "Backends/CLX" "image">. 3: [ACCEPT] Continue, treating compiling #<CL-SOURCE-FILE "clim-clx" "Backends/CLX" "image"> as having been successful. 4: [ABORT] Give up on "mcclim" 5: [RETRY] Retry SLIME REPL evaluation request.

I'm not certain this is the way to fix it, but it seems you don't have the clx package installed. So, in your case, I would try:

(ql:quickload :clx)

and then: (ql:quickload :mcclim)

Cheers,

Mariano

On 7/7/12 Jul 7 -3:53 PM, Christophe Rhodes wrote:

Mariano Montone marianomontone@gmail.com writes:

...

So I was wondering why CLIM is dead. It looks like it doesn't have any activity at all. And I think it is a pity, because when I first looked at Listener/Climacs/Debugger/Inspector stuff, I thought it would be a very nice replacement for SLIME, for instance. I'm SLIME user, but I think there's lot of room for improvements in the Lisp tools area, and the CLIM tools + usability improvements + possibilities to extend the tools very easily sounds very good to me.

Well, one argument is that things don't start out equal. Yes, the Listener, Climacs, Debugger and Inspector are pretty good, but they have to compete with other tools out there, not only for functionality but also for maintenance time. Put bluntly, CLIM is sleeping (maybe not dead, because interesting ideas never die :) because there was a lack of person power to keep it awake. I agree that there's a lot of potential in the tools, but there's a lot of potential in all sorts of things and only a limited amount of time to spend developing that potential.

A particularly challenging aspect of McCLIM is the need to support multiple back-ends for multiple different platforms (X, Mac, gtk, qt, Windows), which are not designed to be CLIM-compatible. This requires a lot of non-Lisp expertise, and multiplies the number of active developers required. Toolkits aimed at a widget level, rather than at the primitive level needed to support CLIM widgets may make this particularly challenging.

...

Does anyone know why CLIM is not used anymore? Does it have any very bad design decisions? I'm not really sure about output recording/redisplay, etc (I haven't seen theme elsewhere, as if that could be automatically handled in general). Don't know about composability and layout yet (I'm still struggling a bit with that now). And I also see some bugs, like some refreshing problems when scrolling, but bugs should be fixable.

It's not got terrible design decisions: there are a couple of problems in some layers of the stack, but nothing that couldn't be worked around. Output recording and incremental redisplay are brave ideas, output recording somewhat more salvageable than incremental redisplay, but they don't cost too much if you don't use them. I don't think there's anything fundamentally wrong with CLIM, or fundamentally better in other toolkits: it's just that the pool of talent and energy to perform the pretty thankless task of making it all work to the extent of its potential seems currently unavailable.

In addition, the fact that CLIM takes novel directions (some of them novel in a very good way), means that it takes some retraining to start to use CLIM. It's hard to justify the effort in rethinking one's UI designs onto a platform that is not fully functional.

I found that it was hard to predict which parts of the CLIM spec were fully supported in McCLIM, which added to the difficulty of using the platform. This is an inevitable consequence of how big the CLIM definition is: a smaller, less functional API (compare Tk), is a lot easier to fully support. But it's a disincentive to use CLIM, and it's hard to keep up enthusiasm without programmers coding to it.

I'm not sure if there is an easy-to-identify core of CLIM that could be established as the bit that one would focus on, and make solid, to make it more predictable for programmers trying to use McCLIM.

What would it take? Money, or graduate students, I think.

The problem with getting graduate students on board is that CLIM is no longer research. The unit of currency for graduate students is the minimal publishable increment, and it's not clear how many of those remain in CLIM ;-)