"RS" == Robert Strandh <strandh@labri.fr> writes:
[...snip...] >> But CAN it work properly without a revamped and robust McCLIM? RS> Yes, I think so. I mean, McCLIM is quite stable (in the sense that it RS> is not crashing) and usable. The main problem for Gsharp is that I RS> have had to write more code than I would have wanted to get around RS> current problems with McCLIM. Of course, at some point, it becomes RS> more advantageous to fix McCLIM than to write workarounds. 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. 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. >> In open source terms, I still think the ideal "killer app" would be an >> advanced mathematical document interface. However, that's non-trivial >> in virtually every way imaginable, and would only attract a few >> developers. rtoy has broken the ice with a basic interface to Maxima, >> but a "killer app" level interface would be months and months of work, >> some of it extremely involved. RS> Nice project, definitely. 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! >> for McCLIM to take off it should be >> sufficiently robust to not cause new users any major frustrations >> beyond learning it in the first place. 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. For me, McCLIM is useful because it lets me build UIs that are good for me to use, which mostly means for debugging --- the objects are very "apparent" and I can grab them and wrestle with them in the REPL. To be honest, if I wanted to just write a user interface for real users (FSVO "real"), I'd be inclined to just bolt something onto a lisp server using a more conventional framework, and a different programming language. >> I personally think the next step should be taken - integrate >> the spec with the code itself, and iron out any >> bugs/limitations in the spec that present themselves. RS> There are of course many ways of integrating the code and the spec. RS> There are places in the current code with references to the spec, but RS> I am guessing you want to go further than that. I am not sure I see RS> how such integration would have a major impact on the maintainability RS> of the code, though. 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 :-/ 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. ;-) R