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

Active select

    Date: Thu, 22 Oct 1992 18:14 EDT
    From: Brian Anderson <bha@atc.boeing.com>

    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?

When you use :KEYSTROKE <mumble> to DEFINE-xxx-COMMAND, the best
CLIM can do is to heuristicate the command name.  You yourself can
do much better by calling ADD-KEYSTROKE-TO-COMMAND-TABLE.  When the
type is :COMMAND, the value is an entire command object, not just a
command name.

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

We have gone to great effort, especially in CLIM 2.0, to make CLIM
extensible in every which way.

I didn't test this, but it should work:

(defmethod read-frame-command ((frame <your frame here>) &key stream)
  (declare (ignore stream))
  (with-menu (stream)
    ;;--- Set the size and position of the new stream as you want
    (read-command (frame-command-table frame) :stream stream)))

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

It depends if the X Window manager supports those menus.  CLIM is not in
the business of implementing much look and feel these days, which is as
it should be.  The idea is to leverage off of the work being done by the
C community, not compete with it.
				       
				       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.


0,,
References:
Main Index | Thread Index