DeviceManagerProtocol
public protocol DeviceManagerProtocol : ObjectProtocol
The DeviceManagerProtocol
protocol exposes the methods and properties of an underlying GdkDeviceManager
instance.
The default implementation of these can be found in the protocol extension below.
For a concrete class that implements these methods and properties, see DeviceManager
.
Alternatively, use DeviceManagerRef
as a lighweight, unowned
reference if you already have an instance you just want to use.
In addition to a single pointer and keyboard for user interface input, GDK contains support for a variety of input devices, including graphics tablets, touchscreens and multiple pointers/keyboards interacting simultaneously with the user interface. Such input devices often have additional features, such as sub-pixel positioning information and additional device-dependent information.
In order to query the device hierarchy and be aware of changes in the
device hierarchy (such as virtual devices being created or removed, or
physical devices being plugged or unplugged), GDK provides
GdkDeviceManager
.
By default, and if the platform supports it, GDK is aware of multiple
keyboard/pointer pairs and multitouch devices. This behavior can be
changed by calling gdk_disable_multidevice()
before gdk_display_open()
.
There should rarely be a need to do that though, since GDK defaults
to a compatibility mode in which it will emit just one enter/leave
event pair for all devices on a window. To enable per-device
enter/leave events and other multi-pointer interaction features,
gdk_window_set_support_multidevice()
must be called on
GdkWindows
(or gtk_widget_set_support_multidevice()
on widgets).
window. See the gdk_window_set_support_multidevice()
documentation
for more information.
On X11, multi-device support is implemented through XInput 2.
Unless gdk_disable_multidevice()
is called, the XInput 2
GdkDeviceManager
implementation will be used as the input source.
Otherwise either the core or XInput 1 implementations will be used.
For simple applications that don’t have any special interest in
input devices, the so-called “client pointer”
provides a reasonable approximation to a simple setup with a single
pointer and keyboard. The device that has been set as the client
pointer can be accessed via gdk_device_manager_get_client_pointer()
.
Conceptually, in multidevice mode there are 2 device types. Virtual devices (or master devices) are represented by the pointer cursors and keyboard foci that are seen on the screen. Physical devices (or slave devices) represent the hardware that is controlling the virtual devices, and thus have no visible cursor on the screen.
Virtual devices are always paired, so there is a keyboard device for every
pointer device. Associations between devices may be inspected through
gdk_device_get_associated_device()
.
There may be several virtual devices, and several physical devices could be controlling each of these virtual devices. Physical devices may also be “floating”, which means they are not attached to any virtual device.
Master and slave devices
carlos@sacarino:~$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Wacom ISDv4 E6 Pen stylus id=10 [slave pointer (2)]
⎜ ↳ Wacom ISDv4 E6 Finger touch id=11 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=13 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=14 [slave pointer (2)]
⎜ ↳ Wacom ISDv4 E6 Pen eraser id=16 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Sleep Button id=8 [slave keyboard (3)]
↳ Integrated Camera id=9 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ ThinkPad Extra Buttons id=15 [slave keyboard (3)]
By default, GDK will automatically listen for events coming from all
master devices, setting the GdkDevice
for all events coming from input
devices. Events containing device information are GDK_MOTION_NOTIFY
,
GDK_BUTTON_PRESS
, GDK_2BUTTON_PRESS
, GDK_3BUTTON_PRESS
,
GDK_BUTTON_RELEASE
, GDK_SCROLL
, GDK_KEY_PRESS
, GDK_KEY_RELEASE
,
GDK_ENTER_NOTIFY
, GDK_LEAVE_NOTIFY
, GDK_FOCUS_CHANGE
,
GDK_PROXIMITY_IN
, GDK_PROXIMITY_OUT
, GDK_DRAG_ENTER
, GDK_DRAG_LEAVE
,
GDK_DRAG_MOTION
, GDK_DRAG_STATUS
, GDK_DROP_START
, GDK_DROP_FINISHED
and GDK_GRAB_BROKEN
. When dealing with an event on a master device,
it is possible to get the source (slave) device that the event originated
from via gdk_event_get_source_device()
.
On a standard session, all physical devices are connected by default to the “Virtual Core Pointer/Keyboard” master devices, hence routing all events through these. This behavior is only modified by device grabs, where the slave device is temporarily detached for as long as the grab is held, and more permanently by user modifications to the device hierarchy.
On certain application specific setups, it may make sense
to detach a physical device from its master pointer, and mapping it to
an specific window. This can be achieved by the combination of
gdk_device_grab()
and gdk_device_set_mode()
.
In order to listen for events coming from devices
other than a virtual device, gdk_window_set_device_events()
must be
called. Generally, this function can be used to modify the event mask
for any given device.
Input devices may also provide additional information besides X/Y.
For example, graphics tablets may also provide pressure and X/Y tilt
information. This information is device-dependent, and may be
queried through gdk_device_get_axis()
. In multidevice mode, virtual
devices will change axes in order to always represent the physical
device that is routing events through it. Whenever the physical device
changes, the GdkDevice:n-axes
property will be notified, and
gdk_device_list_axes()
will return the new device axes.
Devices may also have associated “keys” or
macro buttons. Such keys can be globally set to map into normal X
keyboard events. The mapping is set using gdk_device_set_key()
.
In GTK+ 3.20, a new GdkSeat
object has been introduced that
supersedes GdkDeviceManager
and should be preferred in newly
written code.
-
Untyped pointer to the underlying
GdkDeviceManager
instance.Declaration
Swift
var ptr: UnsafeMutableRawPointer! { get }
-
device_manager_ptr
Default implementationTyped pointer to the underlying
GdkDeviceManager
instance.Default Implementation
Return the stored, untyped pointer as a typed pointer to the
GdkDeviceManager
instance.Declaration
Swift
var device_manager_ptr: UnsafeMutablePointer<GdkDeviceManager>! { get }
-
Required Initialiser for types conforming to
DeviceManagerProtocol
Declaration
Swift
init(raw: UnsafeMutableRawPointer)
-
bind(property:
Extension methodto: _: flags: transformFrom: transformTo: ) Bind a
DeviceManagerPropertyName
source property to a given target object.Declaration
Swift
@discardableResult @inlinable func bind<Q, T>(property source_property: DeviceManagerPropertyName, to target: T, _ target_property: Q, flags f: BindingFlags = .default, transformFrom transform_from: @escaping GLibObject.ValueTransformer = { $0.transform(destValue: $1) }, transformTo transform_to: @escaping GLibObject.ValueTransformer = { $0.transform(destValue: $1) }) -> BindingRef! where Q : PropertyNameProtocol, T : ObjectProtocol
Parameters
source_property
the source property to bind
target
the target object to bind to
target_property
the target property to bind to
flags
the flags to pass to the
Binding
transform_from
ValueTransformer
to use for forward transformationtransform_to
ValueTransformer
to use for backwards transformationReturn Value
binding reference or
nil
in case of an error -
get(property:
Extension method) Get the value of a DeviceManager property
Declaration
Swift
@inlinable func get(property: DeviceManagerPropertyName) -> GLibObject.Value
Parameters
property
the property to get the value for
Return Value
the value of the named property
-
set(property:
Extension methodvalue: ) Set the value of a DeviceManager property. Note that this will only have an effect on properties that are writable and not construct-only!
Declaration
Swift
@inlinable func set(property: DeviceManagerPropertyName, value v: GLibObject.Value)
Parameters
property
the property to get the value for
Return Value
the value of the named property
-
connect(signal:
Extension methodflags: handler: ) Connect a Swift signal handler to the given, typed
DeviceManagerSignalName
signalDeclaration
Swift
@discardableResult @inlinable func connect(signal s: DeviceManagerSignalName, flags f: ConnectFlags = ConnectFlags(0), handler h: @escaping SignalHandler) -> Int
Parameters
signal
The signal to connect
flags
The connection flags to use
data
A pointer to user data to provide to the callback
destroyData
A
GClosureNotify
C function to destroy the data pointed to byuserData
handler
The Swift signal handler (function or callback) to invoke on the given signal
Return Value
The signal handler ID (always greater than 0 for successful connections)
-
connect(signal:
Extension methodflags: data: destroyData: signalHandler: ) Connect a C signal handler to the given, typed
DeviceManagerSignalName
signalDeclaration
Swift
@discardableResult @inlinable func connect(signal s: DeviceManagerSignalName, flags f: ConnectFlags = ConnectFlags(0), data userData: gpointer!, destroyData destructor: GClosureNotify? = nil, signalHandler h: @escaping GCallback) -> Int
Parameters
signal
The signal to connect
flags
The connection flags to use
data
A pointer to user data to provide to the callback
destroyData
A
GClosureNotify
C function to destroy the data pointed to byuserData
signalHandler
The C function to be called on the given signal
Return Value
The signal handler ID (always greater than 0 for successful connections)
-
onDeviceAdded(flags:
Extension methodhandler: ) The
device-added
signal is emitted either when a new master pointer is created, or when a slave (Hardware) input device is plugged in.Note
This represents the underlyingdevice-added
signalDeclaration
Swift
@discardableResult @inlinable func onDeviceAdded(flags: ConnectFlags = ConnectFlags(0), handler: @escaping (_ unownedSelf: DeviceManagerRef, _ device: DeviceRef) -> Void) -> Int
Parameters
flags
Flags
unownedSelf
Reference to instance of self
device
the newly added
GdkDevice
.handler
The signal handler to call Run the given callback whenever the
deviceAdded
signal is emitted -
deviceAddedSignal
Extension methodTyped
device-added
signal for using theconnect(signal:)
methodsDeclaration
Swift
static var deviceAddedSignal: DeviceManagerSignalName { get }
-
onDeviceChanged(flags:
Extension methodhandler: ) The
device-changed
signal is emitted whenever a device has changed in the hierarchy, either slave devices being disconnected from their master device or connected to another one, or master devices being added or removed a slave device.If a slave device is detached from all master devices (
gdk_device_get_associated_device()
returnsnil
), itsGdkDeviceType
will change toGDK_DEVICE_TYPE_FLOATING
, if it’s attached, it will change toGDK_DEVICE_TYPE_SLAVE
.Note
This represents the underlyingdevice-changed
signalDeclaration
Swift
@discardableResult @inlinable func onDeviceChanged(flags: ConnectFlags = ConnectFlags(0), handler: @escaping (_ unownedSelf: DeviceManagerRef, _ device: DeviceRef) -> Void) -> Int
Parameters
flags
Flags
unownedSelf
Reference to instance of self
device
the
GdkDevice
that changed.handler
The signal handler to call Run the given callback whenever the
deviceChanged
signal is emitted -
deviceChangedSignal
Extension methodTyped
device-changed
signal for using theconnect(signal:)
methodsDeclaration
Swift
static var deviceChangedSignal: DeviceManagerSignalName { get }
-
onDeviceRemoved(flags:
Extension methodhandler: ) The
device-removed
signal is emitted either when a master pointer is removed, or when a slave (Hardware) input device is unplugged.Note
This represents the underlyingdevice-removed
signalDeclaration
Swift
@discardableResult @inlinable func onDeviceRemoved(flags: ConnectFlags = ConnectFlags(0), handler: @escaping (_ unownedSelf: DeviceManagerRef, _ device: DeviceRef) -> Void) -> Int
Parameters
flags
Flags
unownedSelf
Reference to instance of self
device
the just removed
GdkDevice
.handler
The signal handler to call Run the given callback whenever the
deviceRemoved
signal is emitted -
deviceRemovedSignal
Extension methodTyped
device-removed
signal for using theconnect(signal:)
methodsDeclaration
Swift
static var deviceRemovedSignal: DeviceManagerSignalName { get }
-
onNotifyDisplay(flags:
Extension methodhandler: ) The notify signal is emitted on an object when one of its properties has its value set through
g_object_set_property()
,g_object_set()
, et al.Note that getting this signal doesn’t itself guarantee that the value of the property has actually changed. When it is emitted is determined by the derived GObject class. If the implementor did not create the property with
G_PARAM_EXPLICIT_NOTIFY
, then any call tog_object_set_property()
results innotify
being emitted, even if the new value is the same as the old. If they did passG_PARAM_EXPLICIT_NOTIFY
, then this signal is emitted only when they explicitly callg_object_notify()
org_object_notify_by_pspec()
, and common practice is to do that only when the value has actually changed.This signal is typically used to obtain change notification for a single property, by specifying the property name as a detail in the
g_signal_connect()
call, like this: (C Language Example):g_signal_connect (text_view->buffer, "notify::paste-target-list", G_CALLBACK (gtk_text_view_target_list_notify), text_view)
It is important to note that you must use canonical parameter names as detail strings for the notify signal.
Note
This represents the underlyingnotify::display
signalDeclaration
Swift
@discardableResult @inlinable func onNotifyDisplay(flags: ConnectFlags = ConnectFlags(0), handler: @escaping (_ unownedSelf: DeviceManagerRef, _ pspec: ParamSpecRef) -> Void) -> Int
Parameters
flags
Flags
unownedSelf
Reference to instance of self
pspec
the
GParamSpec
of the property which changed.handler
The signal handler to call Run the given callback whenever the
notifyDisplay
signal is emitted -
notifyDisplaySignal
Extension methodTyped
notify::display
signal for using theconnect(signal:)
methodsDeclaration
Swift
static var notifyDisplaySignal: DeviceManagerSignalName { get }
-
getClientPointer()
Extension methodReturns the client pointer, that is, the master pointer that acts as the core pointer for this application. In X11, window managers may change this depending on the interaction pattern under the presence of several pointers.
You should use this function seldomly, only in code that isn’t triggered by a
GdkEvent
and there aren’t other means to get a meaningfulGdkDevice
to operate on.get_client_pointer is deprecated: Use gdk_seat_get_pointer() instead.
Declaration
Swift
@available(*, deprecated) @inlinable func getClientPointer() -> DeviceRef!
-
getDisplay()
Extension methodGets the
GdkDisplay
associated todevice_manager
.Declaration
Swift
@inlinable func getDisplay() -> DisplayRef!
-
listDevices(type:
Extension method) Returns the list of devices of type
type
currently attached todevice_manager
.list_devices is deprecated: , use gdk_seat_get_pointer(), gdk_seat_get_keyboard() and gdk_seat_get_slaves() instead.
Declaration
Swift
@available(*, deprecated) @inlinable func listDevices(type: GdkDeviceType) -> GLib.ListRef!
-
clientPointer
Extension methodReturns the client pointer, that is, the master pointer that acts as the core pointer for this application. In X11, window managers may change this depending on the interaction pattern under the presence of several pointers.
You should use this function seldomly, only in code that isn’t triggered by a
GdkEvent
and there aren’t other means to get a meaningfulGdkDevice
to operate on.get_client_pointer is deprecated: Use gdk_seat_get_pointer() instead.
Declaration
Swift
@inlinable var clientPointer: DeviceRef! { get }
-
display
Extension methodUndocumented
Declaration
Swift
@inlinable var display: DisplayRef! { get }