CLIM mail archive
[Prev][Next][Index][Thread]

clim2, command-enabled, and the menu-bar

    Date: Fri, 21 Jan 1994 08:37 EST
    From: berni@iml.fhg.de

    I am asking this question because I cant find any answers in the clim
    2.0 specification.

    If a frame is using a look-and-feel specified menu-bar (e.g., a motif
    menu-bar), is the implementation required to deactivate a menu-item
    button for a command whose (command-enabled ...) method returns nil?

I don't think the spec *requires* the implementation to do anything, but
it is certainly highly desirable for the button to be disabled.

    All I found in the spec is that if someone does (setf (command-enabled
    ...) nil) then a method (note-command-en(dis)abled ...) is called and
    it is "expected" that the corresponding menu-items are changed
    accordingly.

Yup.

    What I would even like better is the following behavior which would be
    more consistent with CLIM's own command-menu-pane behavior:

    As far as I understand, the sensitivity of CLIM's menu-items are
    controlled by the applicabilty of presentation-to-command-translators.

Only CLIM's "home-grown" command menus use translators.  The toolkit-based
menus are certainly not required to use any of the translator mechanism
to do their work.  That could really kill the performance of such menus.

    The effect is that If a (command-enabled <command>) returns nil, then
    the translator is not applicable and hence the item is not "mouse
    sensitive".

    I would like the the motif-style pull-donw-menus work the following way:
    when a pull-down menu is displayed and a button of that menu contains a
    command, then it is checked whether the command is enabled and
    accessible and the activation status of the button gadget is set
    approriately. The advantage is that the "enabled" status of a command
    menu-item can not only be changed by the (setf (command-enabled ...) ..)
    method, but also by specialised methods like

    (defmethod command-enabled ((command (eql 'com-foo) frame &optional comtab))
      ...)

I agree that "it would be nice", but I don't think the performance
implications make it worthwhile.  I think you would be better off having
your specialized COMMAND-ENABLED method call (SETF COMMAND-ENABLED)
itself when its enabled state changes.

    This approach seems far more approriate because in this case the command
    itself can decide whether is is applicable or not in a given state.
    Otherwise everyone who changes a state must know what commands are
    affected --- which may be very difficult.

    So my question: What does the spec require and how do the existing CLIM
    implementations behave?

I'm pretty sure the implementations on Genera, Allegro, and LispWorks
behave w.r.t. (SETF COMMAND-ENABLED).  I am equally sure that they do
not do what you want.
References:
Main Index | Thread Index