CLIM mail archive


define-command vs. define-presentation-to-command-translator

ACL CLIM 2.0 final

I have the following defined, in various places in my source:

(define-command (com-describe-part :command-table describe
				   :menu "Part")
    ((part '(and generic-object (satisfies part-p))
	   :gesture :describe
	   :documentation "The part to describe."))
  (let* ((frame *application-frame*)
	 (parent (ke:focus-object frame))
	 (K-num (ke:current-K-cluster frame))
	 (K-cluster (get-K-cluster K-num parent)) )
    (describe-part part K-cluster))

(define-command (com-describe-S-object :command-table describe
				       :menu "S-object")
    ((gSobj 'generic-S-object
	    :gesture :describe
	    :documentation "The S-object to describe."))
  (describe-S-object gSobj)

In my system, generic-S-object is a direct subclass of
generic-object.  When I run my system, the only action applicable on
objects which satisfy part-p is describe-S-object.  Obviously, this
could be a priority problem, but when I access the right button menu
for such an object, the describe-part command doesn't show up.  If I
access the command from the menu-bar, then only the parts are
selectable, which is correct.  To get my code to work, I have to also
include the following form:

(define-presentation-to-command-translator part-describe
    (generic-object com-describe-part describe
		    :gesture :describe
		    :tester ((object)
			     (part-p object))
		    :priority 10)

Then, everything works the way I want, and I don't need the :gesture
:describe in the command definition.

Obviously, even if it worked without the translator being defined,
there's still a potential problem with priorities, so I likely should
have the translator anyway, but I'm still curious.

If describe-S-object had a higher priority than describe-part, would
that inhibit describe-part from showing up in the right-button menu
of a part?  If not, is there something else wrong with my code?  Or
is it a bug in this implementation of CLIM?

By the way, I have other analagous commands that both take objects of
the exact same class (generic-S-object), with one version using (and
generic-S-object (satisfies <some-function>)) and the other using
generic-S-object, so the generic-object/generic-S-object distinction
doesn't seem to be the root cause of the problem.

Thanks for any help you can give.


Randy A. Coulman, M.Sc.         |       ARIES Laboratory
Research Assistant              |       Department of Computational Science
                                |       University of Saskatchewan             |       Saskatoon, SK   S7N 0W0             

Main Index | Thread Index