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

Active select


|     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.

Just groping for ways to solve the problem.  Maybe this has nothing to
do with any conceivable solution.  Too much free association on the
net can bite you!

|     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.

Accelerators (in their current incantation) accelerator the *command
name*.  Command argument input is  still accomplished thru a textual
typed interface.  Do the CLIM demos have accelerators for commands
with arguments?

|     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.

Yes, an exercise for the student.  The was one of the complaints I had
with DW.  You *could* do it but it was next to imposible for users to
do it.  Especially w.r.t. the frame top level.  I remember Unix people
always touting the fact the the shell was just another program and you
could write your own.  Sure, but how many shells were really written?
Maybe this would be a good contribution to the clim library?  I think
it would be major cool to have multiple top level's for frames that
implement different interface semantics!  It would also be major cool
to have source examples of sophisticaed frame top levels with which to
create your own top level.  Kinda promote extensibility eh?

|     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.

Does that mean that on X windows I can do pull-down, slide-off, tear
off menus or is this not allowed?  Is this "style" only for the Mac?
Seems to me that I also want to attach interaction styles/semantics to
my application and realize it on a particular box.  If it makes sense
for the application to have pull-down menus so be it.  Realize it
as best as possible using the host window system.

|     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".
| 

How about application behavior?


0,,
Follow-Ups: References:
Main Index | Thread Index