When CLIM is waiting for input (inside a with-input-context) it is responsible for determining what translators are applicable to which presentations in a given input context. This loop both provides feedback in the form of highlighting sensitive presentations and is responsible for calling the applicable translator when the user presses a pointer button.
with-input-context uses frame-find-innermost-applicable-presentation (via highlight-applicable-presentation) as its "input wait" handler, and frame-input-context-button-press-handler as its button press "event handler".
Given a presentation, an input context established by with-input-context, and a user gesture, translator matching proceeds as follows.
The set of candidate translators is initially those translators accessible in the command table in use by the current application. For more information, see 11.3 Command Objects.
A translator "matches" if all of the following are true. Note that these tests are performed in the order listed.
(or integer string) and presentation's type is integer).t or is the same as the gesture that the user could perform with the current chord of modifier keys.t.:tester-definitive option is not used in the translator, the value returned by the body of the translator must be presentation-typep of the input context type. In define-presentation-to-command-translator and define-presentation-action, the tester is always definitive.
The algorithm is somewhat more complicated in the case of nested presentations and nested input contexts. In this situation, the sensitive presentation is the smallest presentation that matches the innermost input context.
When there are several translators that match for the same gesture, the one with the highest :priority is chosen (see define-presentation-translator).
Roughly speaking, the current input context indicates what type of input CLIM is asking the user for. You can establish an input context in CLIM with the following constructs:
The input context designates a presentation type. However, the way to accept one type of object may involve accepting other types of objects as part of the procedure. (Consider the request to accept a complex number, which is likely to involve accepting two real numbers.) Such input contexts are called nested. In the case of a nested input context, several different context presentation types can be available to match the to-presentation-types of presentation translators.
Each level of input context is established by a call to accept. The macro with-input-context also establishes a level of input context.
The most common cause of input context nesting is accepting compound objects. For example, you might define a command called Show File, which reads a sequence of pathnames. When reading the argument to the Show File command, the input context contains pathname nested inside of (sequence clim:pathname). Acceptable keyboard input is a sequence of pathnames separated by commas. A presentation translator that translates to a (sequence clim:pathname) supplies the entire argument to the command, and the command processor moves on to the next argument. A presentation translator that translates to a pathname is also applicable. It supplies a single element of the sequence being built up, and the command processor awaits additional input for this argument, or the entry of a SPACE or RETURN to terminate the argument.
When the input context is nested, sensitivity considers only the innermost context type that has any applicable presentation translators for the currently pressed chord of modifier keys.
Presentations can overlap on the screen, so there can be more than one presentation at the pointer location. Often when two presentations overlap, one is nested inside the other.
One cause of nesting is presentations of compound objects. For example, a sequence of pathnames has one presentation for the sequence, and another for each pathname.
When there is more than one candidate presentation at the pointer location, CLIM must decide which presentation is the sensitive one. It starts with the innermost presentation at the pointer location and works outwards through levels of nesting until a sensitive presentation is discovered. This is the innermost presentation that has any applicable presentation translators to any of the nested input context types for the currently pressed chord of modifier keys. Searching in this way ensures that a more specific presentation is sensitive. Note that nested input contexts are searched first, before nested presentations. For presentations that overlap, the most recently presented is searched first.
CLIM 2.0 User Guide - 01 Dec 2021 19:38:57