Robert Strandh strandh@labri.fr writes:
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:
The more general problem I see is that whenever I feel like working on some feature of McCLIM, I feel stymied because of the lack of maintainability of McCLIM.
I don't think it's that bad, to be honest. McCLIM doesn't do too many obscure things, except that a newcomer may be confused about where exactly events are read (I certainly was).
- Remove commented-out code, or uncomment it.
Definitely, I heavily dislike commented-out code.
- Add signed-and-dated comments to difficult passages whenever reasonable.
I'm not sure I like this. I much prefer relying on the version control system to provide me with this kind of information.
- Make sure McCLIM compiles with as few warnings as possible
This is a no-brainer, and I already did some work on it back in November, I think. Most of the remaining warnings are missing defgenerics, which is a lot of work, but not hard at all.
- Add references to the spec for code that implements some required functionality.
Isn't this reference just the name of the function in question?
It is hard to tell what is missing because some parts of the spec are optional, such as color blending for instance.
I don't think it is necessary for us to implement all optional parts before a stable release.
But it might not be highest priority to implement all of the spec. I would say it is more urgent to make the parts that are currently implemented work according to the spec. I am thinking of things like output-record inheriting from standard-rectangle and then assuming all output records do so.
I think it's very important to have a full implementation of the non-optional parts of the spec in a stable release, otherwise it has no meaning.
Again, this sounds good, but that's partly because whether this is reasonable or not depends on what (if any) such extensions are selected.
I think MCCLIM-IMAGES should at least be selected, because it's useful and somewhat simple. I don't know what else. Perhaps Freetype should stop being Experimental and become an Extension?
I think we should have at least one backend that uses a single mirrored sheet (the graft, I suppose), so that we can test unusual sheet transformations and such. The X-window-as-frame-buffer backend I suggested above would do that, but perhaps Gtkairo will as well.
This is mostly related to testing, not to actual use. Thus, while it would be useful, I don't think it is critically important to a stable McCLIM release.
* 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.I am starting to think that docstrings are evil (because they are mostly noise to the person reading the code). I would like to discuss the possibility of using (SETF DOCUMENTATION) instead.
I think they are just as useful as comments to the person reading the code. I'm not a fan of (SETF DOCUMENTATION), as it separates the documentation from the code, making it easier for the two to get out of sync.
* Documentation covering CLIM itself. The spec will have to do for now.What do you mean by this?
I don't like the CLIM spec too much, and I would like to revise it into something that is more usable. This would probably involve more examples and descriptions of how the functions actually behave in McCLIM (the spec is sometimes unclear or nonsensical).