Rainer Joswig joswig@lisp.de writes:
I think one also should look whether the implemented facilities are usable (look and feel also) and correctly drawn.
While look & feel is obviously important for a GUI programming toolkit, I think the focus for a 2.0 release should be on spec compliance, with look & feel being a secondary goal to be worked on once it's clear that a full spec implementation has been reached (or is close).
Are the implemented gadgets working?
How about menus, choices, accepting values dialogs, etc?
Is incremental updating working?
These are all instances of "do we implement the spec?" (The answer is no for some of those.) I've heard that incremental output, as described in the spec, is not feasible to implement, does anyone have knowledge about that? Otherwise, my experience is that it works pretty well.
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.
The biggest problem with define-application-frame is that it has confusing semantics and a lot of different ways to express similar things. We can't really change this, as it's demanded by the spec (right?), but perhaps we could emit some warnings for common errors. In any case, that is secondary to making sure it works as specified.