Trait wayland_client::protocol::wl_seat::Handler
[−]
[src]
pub trait Handler { fn capabilities(&mut self,
evqh: &mut EventQueueHandle,
proxy: &WlSeat,
capabilities: Capability) { ... } fn name(&mut self,
evqh: &mut EventQueueHandle,
proxy: &WlSeat,
name: String) { ... } }
Provided Methods
fn capabilities(&mut self,
evqh: &mut EventQueueHandle,
proxy: &WlSeat,
capabilities: Capability)
evqh: &mut EventQueueHandle,
proxy: &WlSeat,
capabilities: Capability)
seat capabilities changed
This is emitted whenever a seat gains or loses the pointer, keyboard or touch capabilities. The argument is a capability enum containing the complete set of capabilities this seat has.
When the pointer capability is added, a client may create a wl_pointer object using the wl_seat.get_pointer request. This object will receive pointer events until the capability is removed in the future.
When the pointer capability is removed, a client should destroy the wl_pointer objects associated with the seat where the capability was removed, using the wl_pointer.release request. No further pointer events will be received on these objects.
In some compositors, if a seat regains the pointer capability and a client has a previously obtained wl_pointer object of version 4 or less, that object may start sending pointer events again. This behavior is considered a misinterpretation of the intended behavior and must not be relied upon by the client. wl_pointer objects of version 5 or later must not send events if created before the most recent event notifying the client of an added pointer capability.
The above behavior also applies to wl_keyboard and wl_touch with the keyboard and touch capabilities, respectively.
fn name(&mut self, evqh: &mut EventQueueHandle, proxy: &WlSeat, name: String)
unique identifier for this seat
In a multiseat configuration this can be used by the client to help identify which physical devices the seat represents. Based on the seat configuration used by the compositor.