The event command provides several facilities for dealing with window system events, such as defining virtual events and synthesizing events. The command has several different forms, determined by the first argument. The following forms are currently supported:
The following options are supported for the event generate command. These correspond to the ``%'' expansions allowed in binding scripts for the bind command.
NotifyAncestor NotifyNonlinearVirtual NotifyDetailNone NotifyPointer NotifyInferior NotifyPointerRoot NotifyNonlinear NotifyVirtualValid for Enter, Leave, FocusIn and FocusOut events. Corresponds to the %d substitution for binding scripts.
Any options that are not specified when generating an event are filled with the value 0, except for serial, which is filled with the next X event serial number.
In order for a virtual event binding to trigger, two things must happen. First, the virtual event must be defined with the event add command. Second, a binding must be created for the virtual event with the bind command. Consider the following virtual event definitions:
event add <<Paste>> <Control-y> event add <<Paste>> <Button-2> event add <<Save>> <Control-X><Control-S> event add <<Save>> <Shift-F12>In the bind command, a virtual event can be bound like any other builtin event type as follows:
bind Entry <<Paste>> {%W insert [selection get]}
The double angle brackets are used to specify that a virtual event is being bound. If the user types Control-y or presses button 2, or if a <<Paste>> virtual event is synthesized with event generate, then the <<Paste>> binding will be invoked. If a virtual binding has the exact same sequence as a separate physical binding, then the physical binding will take precedence. Consider the following example:
event add <<Paste>> <Control-y> <Meta-Control-y>
bind Entry <Control-y> {puts Control-y}
bind Entry <<Paste>> {puts Paste}
When the user types Control-y the <Control-y> binding will be invoked, because a physical event is considered more specific than a virtual event, all other things being equal. However, when the user types Meta-Control-y the <<Paste>> binding will be invoked, because the Meta modifier in the physical pattern associated with the virtual binding is more specific than the <Control-y> sequence for the physical event. Bindings on a virtual event may be created before the virtual event exists. Indeed, the virtual event never actually needs to be defined, for instance, on platforms where the specific virtual event would meaningless or ungeneratable.
When a definition of a virtual event changes at run time, all windows will respond immediately to the new definition. Starting from the preceding example, if the following code is executed:
bind <Entry> <Control-y> {}
event add <<Paste>> <Key-F6>
the behavior will change such in two ways. First, the shadowed <<Paste>> binding will emerge. Typing Control-y will no longer invoke the <Control-y> binding, but instead invoke the virtual event <<Paste>>. Second, pressing the F6 key will now also invoke the <<Paste>> binding.