Paolo Amoroso wrote:
rpgoldman@real-time.com writes:
[...snip...]
- 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