[mcclim-devel] Why is CLIM dead
Hi. A CLIM/McCLIM newbie here. I've been reading about CLIM and playing a little with McCLIM, and it looks quite good to me. I have been able to prototype some tools very quickly. 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. 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. I appreciate your feedback. Thanks, Mariano
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
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
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
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
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 ;-)
From: Robert Goldman <rpgoldman@sift.info>
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. One of THE main challenges any time anyone wants to build a cross-platform graphical toolkit, actually. Qt probably does about the best job I know of of behaving well across Windows, Mac OSX and X environments - it's a lot of work. Tk does OK, particulary given its small size and age, but it struggles with some of the newer environments like Aqua.
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.
There's sort of a fundamental conceptual collision between wanting to do cross platform GUIs that respect the "native" environment, and implementing novel interface concepts. Part of being "native" is you have to accept and respect the conventions established by the native graphics system. But what happens when they collide with what you want to do graphically? If you want to locally ignore the standard convention, how hard is it to do so? OSX, Windows, KDE, Gnome, etc. each have their own notions of desktop and widget appearance.
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.
That's one of the things I've always wondered about with CLIM generally - is its approach just generally incompatible with the "assemble standard widgets quickly to create a useful app and plug in the app-specific bits into that general framework" approach that seems to be common these days, or is it just that the widget library just doesn't exist for CLIM? I.e. do you lose the possibility of the novel ideas if you support "standard" GUI programming concepts?
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.
That thought has occurred to me before - is there any possibility of defining some sort of universal low-level functionality layer that would be "necessary and sufficient" for basic (non-native appearance) CLIM (or other high level toolkit, for that matter)? Some of the pieces are there (clx, beagle, graphic-forms) but (IMHO) they would need to be welded into something that provides a solid, consistent, regression-testable base before there's any chance of *any* lisp cross platform GUI toolkit (McCLIM, Garnet, whoever) being something that could be built upon as a serious tool.
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 ;-)
Quasi-related question - given where desktop user interface design has gone since the days when CLIM was originally written, is CLIM still the design document that would be created today if we were to write the "what we want for an ideal Lisp graphical toolkit" design document? If not, perhaps a new generation Lisp Graphical Toolkit project could be a viable research direction? Survey the APIs of the existing high level and low level graphics layers and propose a new "meta" GUI definition? Or, if we go with the "find a fun hack" approach - since Tk is a popular toolkit to interface with (ltk) maybe a "low level lisp graphics" layer could be constructed by wrapping existing and (if needed) implementing new low level lisp graphics functionality to support running ltk lisp code without Tk? Cheers, CY
participants (6)
-
Bill Sauer -
Bruce Seely -
C Y -
Christophe Rhodes -
Mariano Montone -
Robert Goldman