[mcclim-devel] One char patch to presentation-defs [really future of McCLIM]

[Robert Strandh]

rpgoldman at 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. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------