[mcclim-devel] questions about CLIM interface paradigm

[Robert P. Goldman]

Paolo Amoroso wrote:

> rpgoldman at 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