"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