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