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

presentation actions

    Date: Thu, 7 Feb 1991 15:22 EST
    From: David Gadbois <AI.gadbois@mcc.com>

	Date: Thu, 7 Feb 1991 14:05-0500
	From: Scott McKay <SWM@sapsucker.scrc.symbolics.com>

	    Date: Thu, 7 Feb 1991 12:03 EST
	    From: kanderso@dino.bbn.com

	    We were suprised to find that CLIM 0.9 did not have
	    define-presentation-action, so Jeff Morrill wrote one:

	If you think you want presentation actions, you are probably wrong.
	They are used for one thing only: performing some sort of action
	inside of the context of the input editor.  The only sorts of things
	that are appropriate to do inside the input editor are (1)
	displaying menus, (2) displaying additional information that will be
	helpful in constructing commands, and (3) simple reformatting of
	displayed data (for example, the expansion of ellipses in a list of
	possibilities).  Any use of a presentation action to do something
	application specific is incorrect, and should be recast as an
	application command plus an ordinary translator.

    OK, but then what is the canonical way of doing some side effect without
    going through a command?  For example, suppose I wanted to have some
    mosue-sensitive buttons that control what is being displayed like those
    little triangle things in Mac OS 7 directory listings.  I though that
    presentation actions would be the way to implement these.  Or is this
    kind of usage considered to be OK?

I haven't yet seen MacOS 7, so I don't know what it is you are referring
to.  If it is just redisplay of data that can take place independent of
changing application state, then it might be OK.  However, if those
triangles are only active at some sort of conceptual top-level state,
then they should be done with translators.

I also don't really understand what the resistance is to "going through
a command", since it is no more or no less expensive than an action.
The only difference is that actions get run deep in the guts of the
input editor.

    Furthermore, I can think of reasonable interfaces where one would prefer
    not to have command lines appearing at all.  For these, I would do all
    the work with actions.  (I just realized you might be able to access
    application commands via command translators without having some king of
    echo area -- is this possible?)

"Commands" and "having command lines appear" are separate things.  You need
not specify an interactor pane in a CLIM application frame.  Furthermore,
we plan to make CLIM have the DW feature of not echoing commands if you ask
it not to.

    And why is it a bad thing to use actions for other than the uses you
    mention?

If I could show you some of the ways people have misused actions, you would
understand why I am trying to tilt the pendulum the other way.  But I
can't, because they're not mine to show.  The problem with actions is that
you can get subtle problems from doing stuff inside the input editor.  For
instance, your interactive streams may not be what you think, or you might
end up recursively invoking your applications command parsing loop without
knowing it.  (Right now, we are helping to straighten out a large program
with some subtle, hard-to-fix problems that are exactly caused by using
actions instead of translators.)

The real point behind my message is that actions are the *exception*, not
the rule.  Use translators.  Every so often, you will want to use an action
because a translator will cause you to lose the state of a command you are
trying to enter.  But not very often.  I realize this sounds a lot like
"trust me", but really, please trust me on this one.

Dave Moon's message on the subject is worth reading again.

0,,
References:
Main Index | Thread Index