[mcclim-devel] questions about CLIM interface paradigm
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
rpgoldman@real-time.com writes:
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.
Possibly likewise ;-)
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?
Doesn't CLIM already take care of this in interactor panes, e.g. with required and keyword arguments? See for example the CLIM Listener commands Show Class Subclasses/Superclasses.
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?
When you have many inputs of different types, you may use accepting-values.
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,
What about views?
2. Is it good style to use the Enabled method? Is there a standard
I think this is a general UI issue, not necessarily a CLIM one.
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....
You may keep a table associating commands with lists of commands to enable/disable. Each entry could also include tests for checking whether to actually disable/enable commands. The commands that need to do that could access the appropriate entry, run the tests, and enable/disable the relevant commands. It should be possible to hide much of this complexity to a CLIM application. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Paolo Amoroso wrote:
rpgoldman@real-time.com writes:
[...snip...]
2. Is it good style to use the Enabled method? Is there a standard
I think this is a general UI issue, not necessarily a CLIM one.
I actually think that this /is/ a specifically CLIM issue --- if CLIM simply removes disabled interactions from the UI, instead of leaving them there in a visibly-disabled form, then one may feel compelled to modify the way disablement is handled, or reimplement a custom disablement behavior. Down below, I will mention another reason why this might be a CLIM issue.
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....
You may keep a table associating commands with lists of commands to enable/disable. Each entry could also include tests for checking whether to actually disable/enable commands. The commands that need to do that could access the appropriate entry, run the tests, and enable/disable the relevant commands. It should be possible to hide much of this complexity to a CLIM application.
I see I wasn't clear enough in my first email. Actually, writing methods for "enabled" is really easy, and substantially cleans up my code for the commands themselves. On the other hand, I really don't want my user interface to be playing "hide-and-seek" with command names. Instead, if there's something about the current situation that makes a command be disabled, I'd like it to be displayed in some form that's effectively a "gray-out." This leads to my second point about why this might be a CLIM issue. It seems to me at least possible that there are TWO different kinds of enablement and disablement, which I will call (relatively) static and dynamic. The static case would correspond to application contexts where the command is inappropriate. E.g., if you have a browser for two different kinds of objects (say a schedule and a map), that application might have two different layouts, and some commands would be appropriate when in one layout and other commands would be appropriate in the other. That seems like a static case, and one where you might well NOT want the "gray out". Instead there would be two different contexts, with two different interfaces, and different sets of active commands. This seems like the case that the existing enablement protocol handles well. BUT, there is also another case, the "dynamic" case, where there may be short-lived situations that make a particular command inappropriate. For lack of a better example, consider some form of interface where one is editing a document. This document can be saved to a file. One might have the conventional "save" and "save as" commands. The former would be dynamically/temporarily disabled until a file name is associated with the current document, so that if you create an initial document, initially only the "Save as" is fully usable, and "Save" should be grayed out (if you open an existing document, the "Save" should be available immediately). Then, when a file name is associated with the document, the "Save" command would no longer be grayed out. IIUC, it is this latter case that is not supported by the existing CLIM protocols. Am I correct in this assumption? If so, how hard would it be to fix that problem? Presumably the command menu and menu bar objects could be subclassed to support this kind of dynamic disabling, yes? Cheers, R
"Me" == Robert P Goldman <rpgoldman@real-time.com> writes:
Me> Paolo Amoroso wrote: >> rpgoldman@real-time.com writes: >> >> Me> [...snip...] >>> 2. Is it good style to use the Enabled method? Is there a standard >> >> >> I think this is a general UI issue, not necessarily a CLIM one. Me> I actually think that this /is/ a specifically CLIM issue --- if CLIM Me> simply removes disabled interactions from the UI, instead of leaving Me> them there in a visibly-disabled form, then one may feel compelled to Me> modify the way disablement is handled, or reimplement a custom Me> disablement behavior. OK, I see that this was unclear, mirroring my own confusion, but somewhat reinforced by what feels like inconsistency in McCLIM. When I make a menubar, then disabling is handled in the "dynamic" style I referred to in my email, and disabled items are grayed out. This seems fine. *But* when I just use the right menu button, then *all* commands are shown, whether they are enabled or disabled. Question: should we be modifying McCLIM to make the right button menu act like the menu bar, or vice versa? I favor the former, but defer to wiser heads.... Cheers, R
On Jul 23, 2005, at 1:32 AM, rpgoldman@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
"TM" == Timothy Moore <moore@bricoworks.com> writes:
TM> On Jul 23, 2005, at 1:32 AM, rpgoldman@real-time.com wrote: >> 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.... >> TM> Some clever handler established with handler-bind, left as an exercise TM> for the reader :) I think the problem is that the CERROR recovery code can do something pretty arbitrary, and I don't believe there's any obvious way to introspect in the handler to guess what presentation type you need to accept to do what the CERROR handler wants.... R
participants (4)
-
Paolo Amoroso -
Robert P. Goldman -
rpgoldman＠real-time.com
-
Timothy Moore