rpgoldman@real-time.com writes:
I'm afraid that hasn't really been my experience. I can often crash McCLIM when I do something that upsets its processing of ACCEPT, in particular, and updating output seems to work very, very badly with scrolling panes, so badly that I can't think of a single interaction which hasn't required me to iconify and de-iconify the frame to make it repaint reasonably. And usually I have to resize the frame by hand in the process. This seems to me to be pretty far from usable.
OK. I guess I just haven't had to use those parts of McCLIM.
This isn't meant to be whining --- I'm working to help improve the situation. But I'm not as sanguine about the current status. As I mention below, I think we need a bunch more gadgets.
Well, yes, sort of. I mean, since CLIM is so stratified, it is *possible* though not necessarily *desirable* for an application to implement the gadgets it needs. This fact makes it less urgent to add more functionality to McCLIM. I do think stability and compliance are higher up on the list.
One could imagine biting off a smaller piece --- perhaps something involving MathML? But typesetting math is not that easy! It took even Knuth a bunch of years!
TeXmacs does a fairly good job, it seems. Now if we could only convince Joris to use CL and McCLIM...
I think it should also be enhanced to be able to generate interfaces that don't cause their users (as opposed to their programmers) cognitive upset. So there ought to be file-choosers that look mostly like other file-choosers, etc.
Unfortunately, that's a lot of gadgetage to be written.
Yeah, but that's the fairly easy part. Anyone who has a week or so of time to spend could do that.
A simple step that could be taken would be to put bits of the spec into the documentation strings. I don't have the appetite for that level of cut-and-paste drudgery, though :-/
Also, see my previous message. Sometimes there is not a very immediate association between code and spec text.
As far as ironing out bugs and limitations in the spec, we probably need to have a real project owner to make that feasible. Which takes us back to Christophe's original question. ;-)
It is a totally different project in my opinion. To improve the current code, the owner needs to know both the spec and the code. To improve the spec, only a limited amount of knowledge of the code is required.