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

[rpgoldman at real-time.com]

>>>>> "RS" == Robert Strandh <strandh at 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