[mcclim-devel] McCLIM 2.0 in 2008

[Rainer Joswig]

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 at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel