CLIM mail archive
[Prev][Next][Index][Thread]
Active select
Date: Thu, 22 Oct 1992 16:11 EDT
From: Brian Anderson <bha@atc.boeing.com>
Yes I do want to build a more mouse-based interface. I don't want to
type unless I have to!
The above suggestion is OK except it disallows any commands with
arguments. There is no place to accept the arguments from! The
interaction style assumes a textual command-line interface.
Maybe one needs to have another type of menu item to command
translator that does AVV popups for commands with arguments? Then a
way to put this on the :select gesture for menu items.
This is not a bad idea. I might be able to get you started on this.
I guess this is an example of another type of "interaction style." In
my experience with DW and CLIM, folks always want to create their own
interaction styles - but this seems relatively hard to do. Another
example is the dreaded no echo menu items. Maybe there needs to be
more information about how commands and menu items work so that we can
build different interaction styles? Can AVV panes help do the job?
How about different "translators?" Maybe views?
I don't understand the last three questions. Sorry.
CLIM seems to support the typed command-line interface quite well.
Included in this style are keyboard and menu accelerators for this
textual *typed* command-line interface. Command arguments are
gathered thru the typed command line.
You don't need an interactor for accelerators to work. I really think
of accelerators as being quite different from normal typed command
lines. Many of the CLIM demos don't have a command-line interface at
all. I find this style of interface is quite easy to create in CLIM,
much easier than DW.
Another major style that one might concieve of would be to have popups
for gathering the arguments of a command rather than typing them at a
textual interface (:interactor panes). Now keyboard and menu
accelerators would drive this popup style of gathering arguments for a
command. No textual "command-line" would be necessary for this
interaction style (and thus no :interactor pane).
You could actually do this by defining your own READ-FRAME-COMMAND
method that simply pops up a window, reads the command from it by
calling READ-COMMAND, and then returns the command. It should be very
easy for you to do this.
These styles might be extended to include different kinds of menu
accelerators. For example:
o pull-down, slide-off, tear-off menus all with graying for
inactive menu items.
This sort of stuff is really the province of the underlying window
system. CLIM 2.0 supports the abstractions for doing all this.
o pallettes (iconic menus???)
You can do these even in CLIM 1.1, although again, CLIM 2.0 does a
better job of it. In particular, CLIM 2.0 allows iconics items in
dialogs as well for the MEMBER types.
Gee, maybe someday we will have voice accelerators too!
All of these interaction styles eventually invoke "commands" to do
their work. In that way, the implementation is independent of the
interaction style :-) I suppose that keyboard and menu accelerator
declarations don't even have to know the difference in interaction
styles. The "declaration" of the interaction style realizes the
various declared accelerators in the correct way. I presume that this
independence of the "presentation" of a command and its implementation
thru define-command was the basic design concept behind CLIM commands!?
Yes. It's unfortunate that so many people think that a "command" is a
"command line", but it's hard to find a better word than "command" for
"an object to represent a user interaction that tells the application
what to do".
0,,
Follow-Ups:
References:
Main Index |
Thread Index