[mcclim-devel] questions about CLIM interface paradigm

[Timothy Moore]

On Jul 23, 2005, at 1:32 AM, rpgoldman at real-time.com wrote:

>
> 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?
If you're talking about a fixed number of arguments in a fixed order, 
then this is a property of the presentation type of each argument. 
There are also keyword command arguments that allow optional arguments 
in any order.
> 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.
>
I'm not sure what you mean by "modifier," but I'll try to muddle 
through anyway.
> 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?
Well, yes :) But we haven't yet written the accept methods that are 
specialized for "multiple choice" (called completion presentation 
types) in dialog views. We do have one experimental accept method for 
multiple choices that uses a pop-up menu. Look at accepting-values.lisp 
in Examples.
>
> 1.a) To get this behavior, should I be writing a bunch of accept
> methods?
>
You should be defining a bunch of presentation types and, where 
necessary, write accept methods for them. Ideally you would inherit 
from existing presentation types and use their 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?
No. When you call accept, explicitly or implicitly when reading command 
arguments, the user can always click on matching presentations in the 
graphical display. If the input stream is compatible with a text-view 
-- which is the case for an interactor pane -- the user can enter 
textual input at the same time. Typically, the only accept methods that 
you need to write deal with parsing complex input from a text stream.
>  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?
>
Accept is called with a stream (by default a pane that is 
frame-standard-input) and a view, usually a text view.
> [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?]
>
Yes; the boolean presentation type works like that.

> 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.
You have a good point; it is confusing to have commands appear and 
disappear. McCLIM does what CLIM did which is not ideal from a UI point 
of view.
>
> 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....
>
Some clever handler established with handler-bind, left as an exercise 
for the reader :)

Tim