Associating semantics with output is only half of the user interface equation. The presentation type system also supports the input side of the user interaction. When an application wishes to solicit from the user input of a particular presentation type, it establishes an input context for that type. CLIM will then automatically allow the user to satisfy the input request by pointing at a visible presentation of the requested type (or a valid subtype) and pressing a pointer button. Only the presentations that "match" the input context will be "sensitive" (that is, highlighted when the pointer is moved over them) and accepted as input, thus the presentation-based input mechanism supports context-dependent input. [annotate]
[input context, Concept← A Glossary]
[input context, Concept← A Glossary]
[input context, Concept← A Glossary]
Minor issue: What exactly is an input context? What does it mean for them to be nested? --- SWM [annotate]
The current input context. This will be a list, each element of which corresponds to a single call to with-input-context. The first element of the list represents the context established by the most recent call to with-input-context, and the last element represents the context established by the least recent call to with-input-context. [annotate] The exact format of the elements in the list is unspecified, but will typically be a list of a presentation type and a tag that corresponds to the point in the control structure of CLIM at which the input context was establish. *input-context* and the elements in it may have dynamic extent. [annotate] [← 28.4 The Generic Command Loop, run-frame-top-level] [← 28.3.1 Interface with Presentation Types, frame-input-context-button-press-handler] [← 23.7.3 Finding Applicable Presentations, highlight-applicable-presentation] [← 23.7.1 Defining Presentation Translators, define-presentation-translator] [← 23.5 Context-dependent (Typed) Input, with-input-context] [← 23.5 Context-dependent (Typed) Input, input-context-type] |
Given one element from *input-context*, context-entry, returns the presentation type of the context entry. [annotate] |
with-input-context | (type &key override) (&optional object-var type-var event-var options-var) form &body pointer-cases | [Macro] |
Establishes an input context of presentation type type; this must be done by binding *input-context* to reflect the new input context. When the boolean override is false (the default), this invocation of with-input-context adds its context presentation type to the current context. In this way an application can solicit more than one type of input at the same time. When override is true, it overrides the current input context rather than nesting inside the current input context. [annotate] type can be a presentation type abbreviation. [annotate] After establishing the new input context, form is evaluated. If no pointer gestures are made by the user during the evaluation of form, the values of form are returned. Otherwise, one of the pointer-cases is executed (based on the presentation type of the object that was clicked on) and the value of that is returned. (See the descriptions of call-presentation-menu and throw-highlighted-presentation.) pointer-cases is constructed like a typecase statement clause list whose keys are presentation types; the first clause whose key satisfies the condition (presentation-subtypep type key) is the one that is chosen. [annotate] During the execution of one of the pointer-cases, object-var is bound to the object that was clicked on (the first returned value from the presentation translator that was invoked), type-var is bound to its presentation type (the second returned value from the translator), and event-var is bound to the pointer button event that was used. options-var is bound to any options that a presentation translator might have returned (the third value from the translator), and will be either nil or a list of keyword-value pairs. object-var, type-var, event-var, and options-var must all be symbols. [annotate] type, stream, and override are evaluated, the others are not. [annotate] For example, [annotate] (with-input-context ('pathname) (path) (read) (pathname (format t "~&The pathname ~A was clicked on." path))) [← 23.7.4 Translator Applicability] [← 23.7.3 Finding Applicable Presentations, highlight-applicable-presentation] [← 23.7.3 Finding Applicable Presentations, throw-highlighted-presentation] [← 23.7.2 Presentation Translator Functions, call-presentation-menu] [← 23.5 Context-dependent (Typed) Input, accept-1] [← 23.5 Context-dependent (Typed) Input, *input-context*] |
accept | type &key stream view default default-type provide-default insert-default replace-input history active-p prompt prompt-mode display-default query-identifier activation-gestures additional-activation-gestures delimiter-gestures additional-delimiter-gestures | [Function] |
stream-accept | stream type &key view default default-type provide-default insert-default replace-input history active-p prompt prompt-mode display-default query-identifier activation-gestures additional-activation-gestures delimiter-gestures additional-delimiter-gestures | [Generic Function] |
stream-accept is the per-stream implementation of accept, analogous to the relationship between read-char and stream-read-char. All extended input streams must implement a method for stream-accept. The default method (on standard-extended-input-stream) simply calls accept-1. [annotate] The arguments and overall behavior of stream-accept are as for accept-1. [annotate] Rationale: the reason accept is specified as a three-function "trampoline" is to allow close tailoring of the behavior of accept. accept itself is the function that should be called by application programmers. CLIM implementors will specialize stream-accept on a per-stream basis. (For example, the behavior of accepting-values can be implemented by creating a special class of stream that turns calls to accept into fields of a dialog.) accept-1 is provided as a convenient function for the stream-accept methods to call when they require the default behavior. [annotate] |
accept-1 | stream type &key view default default-type provide-default insert-default replace-input history active-p prompt prompt-mode display-default query-identifier activation-gestures additional-activation-gestures delimiter-gestures additional-delimiter-gestures | [Function] |
Requests input of type type from the stream stream. type must be a presentation type specifier. view is a view object that defaults to stream-default-view of stream. accept-1 returns two values, the object representing the input and its presentation type. (If frame-maintain-presentation-histories is true for the current frame, then the returned object is also pushed on to the presentation history for that object.) [annotate] Note: Doesn't it mean "presentation history for that presentation type"? [edit]-- Athas "Troels" Henriksen 2006-11-26 22:42Z accept-1 establishes an input context via with-input-context, and then calls the accept presentation method for type and view. When called on an interactive stream, accept must allow input editing; see Chapter 24 for a discussion of input editing. The call to accept will be terminated when the accept method returns, or the user clicks on a sensitive presentation. The typing of an activation and delimiter character is typically one way in which a call to an accept method is terminated. [annotate] A top-level accept satisfied by keyboard input discards the terminating keyboard gesture (which will be either a delimiter or an activation gesture). A nested call to accept leaves the terminating gesture unread. [annotate] If the user clicked on a matching presentation, accept-1 will insert the object into the input buffer by calling presentation-replace-input on the object and type returned by the presentation translator, unless either the boolean replace-input is false or the presentation translator returned an :echo option of false. replace-input defaults to true, but this default is overridden by the translator explicitly returning an :echo option of false. [annotate] If default is supplied, then it and default-type are returned as values from accept-1 when the input is empty. default-type must be a presentation type specifier. If default is not supplied and provide-default is true (the default is false), then the default is determined by taking the most recent item from the presentation type history specified by history. If insert-default is true and there is a default, the default will be inserted into the input stream by calling presentation-replace-input. [annotate] history must be either nil, meaning that no presentation type history will be used, or a presentation type (or abbreviation) that names a history to be used for the call to accept. history defaults to type. [annotate] prompt can be t, which prompts by describing the type, nil, which suppresses prompting, or a string, which is displayed as a prompt (via write-string). The default is t, which produces "Enter a type:" in a top-level call to accept or "(type)" in a nested call to accept. [annotate] If the boolean display-default is true, the default is displayed (if one was supplied). If display-default is false, the default is not displayed. display-default defaults to true if prompt was provided, otherwise it defaults to false. [annotate] prompt-mode can be :normal (the default) or :raw, which suppresses putting a colon after the prompt and/or default in a top-level accept and suppresses putting parentheses around the prompt and/or default in a nested accept. [annotate] query-identifier is used within accepting-values to identify the field within the dialog. The active-p argument (which defaults to t) can be used to control whether a field within an accepting-values is active; when false, the field will not be active, that is, it will not be available for input. Some CLIM implementations will provide a visual cue that the field is inactive, for instance, by "graying out" the field. [annotate] activation-gestures is a list of gesture names that will override the current activation gestures (which are stored in *activation-gestures*). Alternatively, additional-activation-gestures can be supplied to add activation gestures without overriding the current ones. See Chapter 24 for a discussion of activation gestures. [annotate] delimiter-gestures is a list of gesture names that will override the current delimiter gestures (which are stored in *delimiter-gestures*). Alternatively, additional-delimiter-gestures can be supplied to add delimiter gestures without overriding the current ones. See Chapter 24 for a discussion of delimiter gestures. [annotate] |
Like accept, except that the input is taken from string, starting at the position specified by start and ending at end. view, default, and default-type are as for accept. [annotate] accept-from-string returns an object and a presentation type (as in accept), but also returns a third value, the index at which input terminated. [annotate] |
Called by accept to prompt the user for input of presentation type type on the stream stream for the view view. accept-args are all of the keyword arguments supplied to accept. The default method (on standard-extended-input-stream) simply calls prompt-for-accept-1. [annotate] |
prompt-for-accept-1 | stream type &key default default-type display-default prompt prompt-mode &allow-other-keys | [Function] |
Prompts the user for input of presentation type type on the stream stream. [annotate] If the boolean display-default is true, then the default is displayed; otherwise, the default is not displayed. When the default is being displayed, default and default-type are the taken as the object and presentation type of the default to display. display-default defaults to true if prompt is non-nil, otherwise it defaults to false. [annotate] If prompt is nil, no prompt is displayed. If it is a string, that string is displayed as the prompt. If prompt is t (the default), the prompt is generated by calling describe-presentation-type to produce a prompt of the form "Enter a type:" in a top-level call to accept, or "(type)" in a nested call to accept. [annotate] prompt-mode can be :normal (the default) or :raw, which suppresses putting a colon after the prompt and/or default in a top-level accept and suppresses putting parentheses around the prompt and/or default in a nested accept. [annotate] |