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

[Robert P. Goldman]

>>>>> "TM" == Timothy Moore <moore at bricoworks.com> writes:

    TM> On Aug 9, 2005, at 9:28 PM, rpgoldman at real-time.com wrote:
    >> 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.
    TM> I'm not necessarily disagreeing about the state of accept (more 
    TM> accurately input editing) and incremental redisplay, but I'm having 
    TM> some trouble searching through the mail archives for specific 
    TM> complaints. In particular I have not noticed problems with scrolling 
    TM> and updating-output in my use of it. Do you mind (re)posting some 
    TM> specific bugs?

Tim, sorry to have taken so long to get back to you.  Rereading your
email, I see that I have misled you.  I was referring above to two
*separate* problems.  I.e., (1) I have found it very easy to toss my
McCLIM app into the debugger by typing a bad character in the middle
of ACCEPTing arguments and (2) I have frequently had trouble with
updating output that has left me with a small subset of a scrolling
window redrawn, and with the rest of that window a blank, gray area.

I'm not sure that (1) is a bug, per se.  It's not that ACCEPT ever
returns a bad value, it's just that it is not robust to getting bad
input.  I would have thought that ACCEPT should by default trap the
INPUT-NOT-OF-REQUIRED-TYPE.  As a programmer, I don't see how I can do
this, if ACCEPT doesn't.  I.e., when I write a define-<foo>-command
form, it's internal CLIM stuff that handles getting the arguments for
me, and if I type something wrong, I'd rather not have the application
dumped into the debugger.  So shouldn't that command processing exit
somewhat gracefully by default?

Similarly, as I mentioned earlier, it would be nice if one could use
the ABORT gesture in the middle of ACCEPT and have something good
happen.  Seems like if I type something bad and can't fix it in
input-editing, I'm just doomed to complete the interaction, and then
have the command fail into the debugger.  I looked into this a little,
and it seemed like there was no place in the %ACCEPT code that looked
for an ABORT gesture, but the bottom layers of McCLIM are pretty
mysterious to me.  Is this a GOATEE thing, or should it be handle by
%ACCEPT or ACCEPT-FROM-STREAM?  If you can give me a pointer, I'd be
happy to try to fix it myself.

Best,
R