Re: [mcclim-devel] McCLIM 2.0 in 2008

I think one also should look whether the implemented facilities are usable (look and feel also) and correctly drawn.

Are the implemented gadgets working?

How about menus, choices, accepting values dialogs, etc?

Is incremental updating working?

Is there enough error checking and reporting in define-application- frame? This macro created great frustrations among CLIM users (buggy, poor error checking, non-obvious effects, poor overall robustness). Make mistake and you had to restart the App, or the whole Lisp. I'm not saying that McCLIN has these problems, but it should checked.

Am 15.01.2008 um 23:28 schrieb Troels Henriksen athas@sigkill.dk:

So, McCLIM is already pretty old, and while I can't claim to have worked on it for more than a year and a half, I feel like I have a pretty good grasp of what it does, and how well it does it. Perhaps we should start wondering about releasing a "stable" McCLIM, that is, one that is feature complete (with relation to the CLIM spec) and more tested than out usual releases. I'm not saying we should slap a stable version number on the 0.9.6 release, just that I think it would be a good, and achievable, goal to release a stable version this year. What would need to be done to make this happen? Here's a preliminary list, if you feel it is incomplete, please add to it:

* First, implement all the reasonable parts of the CLIM 2 spec,
  with the exception of things that are unimplementable,
  underspecified or just really hard to do properly (fully
  generic designs, alpha blending and all, falls in this last
  category, I think). Things that are underspecified should
  probably be implemented by looking at later CLIM specs, as well
  as classic CLIM behaviour. We are already mostly there. Does
  anyone know exactly what is missing?

* Create a better test suite, at least something that can
  actually be called a test suite, though it may not fully test
  the entire system. This is probably a must if a "stable"
  release is to have any meaning at all, and fortunately, many of
  the tricky aspects of CLIM do not actually need a graphical
  interface, and the Null backend may suffice for the majority of
  the rest. I would prefer using an actual regression testing
  library (such as FiveAM) compared to files filled with asserts.

* Select a number of extensions (not necessarily all of them) and
  make sure they're as well tested as the core CLIM
  functionality. These extensions should also be documented.

* Have at least one backend without major flaws. I think the CLX
  backend is good enough, apart from some suboptimal
  performance. Gtkairo may not reach that level this year.

* Insert docstrings for all exported functionality. If I recall
  correctly, Robert Strandh spoke with one of the original CLIM
  spec authors and was told not to worry about copyright issues,
  so we could just copy from there.

The following is what is NOT necessary for a McCLIM 2.0 release:

* Support for LispWorks and Allegro CLIM extensions.

* Fully working and tested extensions. We only need to select
  those that are feasible to bring up to a sufficiently high
  level of stability and performance (does this leave out
  mcclim-freetype?). Of course, we should document which ones.

* More than one fully working backend.

* Documentation covering CLIM itself. The spec will have to do
  for now.

Finally: when you saw this email, none of you thought "I wonder what insightful observations this thoughtful engineer has about a stable release", you thought "why is this crazy hacker talking about a 2.0 version, we're still pre-1.0!". My idea is to make the McCLIM version number follow the CLIM spec version number. While this is not terribly useful for a 2.0 release in isolation, it makes it easier to design similar 2.1 and 2.2 releases for the LispWorks and Allegro extensions, as well as the hypothetical future CLIM 2.3 spec that will fix all the ambiguous and underspecified details and bring CLIM into the 90's.

What are your thoughts?

-- \ Troels /\ Henriksen - who's quite sleep-deprived _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel