[mcclim-devel] Why is CLIM dead

[C Y]

> From: Robert Goldman <rpgoldman at 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