On Jul 23, 2005, at 1:32 AM, rpgoldman@real-time.com wrote:
- 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.
- 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....
- 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