[mcclim-devel] questions about CLIM interface paradigm

[rpgoldman at real-time.com]

1.  This is a question about using the CLIM interface paradigm that I know
should have an obvious answer, but I just don't understand where to
find it.

Consider that I have a command with some number of arguments > 1.
Now, I specify a command with argument types.  OK.  Now where do I put
the procedural information about the mechanics of choosing the
arguments?

I have done this in an existing application by the somewhat unpleasant
expedient of having a command just have a single argument, for the
"major" parameter, and then having procedural code that supplies the
modifier arguments.  E.g., there might be some boolean modifiers, and
I provide code that tells CLIM to use a particular way of reading
those modifiers.  At the end of this UI code, we dispatch to the stuff
that does the real work.

But this seems wrong.  Shouldn't I be able to specify the arguments
and their types and have McCLIM Do the Right Thing about reading the
additional arguments?  E.g., know that a set of radiobuttons might be
the right way to collect a multiple-choice modifier argument?

1.a) To get this behavior, should I be writing a bunch of accept
methods?  

1.b) If so, in an app that has an graphical application-pane and an
interactor-pane, should I have one accept method that lets people
click on the corresponding presentations (if any) and a separate one
that will handle textual input?  E.g., if I have objects with names,
then the default accept method would allow users to supply an object
of the right type by just clicking on it; could I add a second method,
specialized for interactor panes, that would allow users to type the
name and which would cause CLIM to somehow lookup the corresponding
data strucure?  And will a simple call to accept allow either form of
input?  Seems like it would, based on my experience, but I wasn't
sure...  Does CLIM just invoke ACCEPT on the application frame, and
have that call to accept simply invoke ACCEPT on the associated panes?

[P.S. shouldn't there be a default method for reading yes or no and
returning T or NIL, as with y-or-n-p?]

2.  Is it good style to use the Enabled method?  Is there a standard
for how CLIM should graphically present disablement?  My understanding
of the current UI dogma is that users should be presented with *all*
the alternatives, both enabled and disabled, and that the disabled
ones should be presented in some form that makes it clear they are
disabled (e.g., pulldown menus with greyed-out alternatives).  Not
showing the disabled ones leaves the user confused about the
facilities offered by the application, and showing the disabled ones
w/o cues, leaves the user frustrated.

Previously I had a lot of code that would handle inappropriate methods
and produce a helpful string or two, but this is repetitive, a blemish
on the design, and can be very large if there is a relatively complex
condition for enablement....  

3.  Is there any reasonable way to handle CERROR in code running
inside a CLIM UI?  Seems like there should be, but I don't really know
how one would go about doing it....

Many thanks,
Robert