The AppLaunchContextProtocol protocol exposes the methods and properties of an underlying GdkAppLaunchContext 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 AppLaunchContext. Alternatively, use AppLaunchContextRef as a lighweight, unowned reference if you already have an instance you just want to use.

GdkAppLaunchContext is an implementation of GAppLaunchContext that handles launching an application in a graphical context. It provides startup notification and allows to launch applications on a specific screen or workspace.

Launching an application

(C Language Example):

GdkAppLaunchContext *context;

context = gdk_display_get_app_launch_context (display);

gdk_app_launch_context_set_screen (screen);
gdk_app_launch_context_set_timestamp (event->time);

if (!g_app_info_launch_default_for_uri ("http://www.gtk.org", context, &error))
  g_warning ("Launching failed: %s\n", error->message);

g_object_unref (context);

The CursorProtocol protocol exposes the methods and properties of an underlying GdkCursor 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 Cursor. Alternatively, use CursorRef as a lighweight, unowned reference if you already have an instance you just want to use.

A GdkCursor represents a cursor. Its contents are private.

The AtomProtocol protocol exposes the methods and properties of an underlying GdkAtom 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 Atom. Alternatively, use AtomRef as a lighweight, unowned reference if you already have an instance you just want to use.

An opaque type representing a string as an index into a table of strings on the X server.

The ColorProtocol protocol exposes the methods and properties of an underlying GdkColor 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 Color. Alternatively, use ColorRef as a lighweight, unowned reference if you already have an instance you just want to use.

A GdkColor is used to describe a color, similar to the XColor struct used in the X11 drawing API.

The DeviceProtocol protocol exposes the methods and properties of an underlying GdkDevice 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 Device. Alternatively, use DeviceRef as a lighweight, unowned reference if you already have an instance you just want to use.

The GdkDevice object represents a single input device, such as a keyboard, a mouse, a touchpad, etc.

See the GdkDeviceManager documentation for more information about the various kinds of master and slave devices, and their relationships.

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.

The DeviceToolProtocol protocol exposes the methods and properties of an underlying GdkDeviceTool 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 DeviceTool. Alternatively, use DeviceToolRef as a lighweight, unowned reference if you already have an instance you just want to use.

The DisplayProtocol protocol exposes the methods and properties of an underlying GdkDisplay 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 Display. Alternatively, use DisplayRef as a lighweight, unowned reference if you already have an instance you just want to use.

GdkDisplay objects purpose are two fold:

• To manage and provide information about input devices (pointers and keyboards)

• To manage and provide information about the available GdkScreens

GdkDisplay objects are the GDK representation of an X Display, which can be described as a workstation consisting of a keyboard, a pointing device (such as a mouse) and one or more screens. It is used to open and keep track of various GdkScreen objects currently instantiated by the application. It is also used to access the keyboard(s) and mouse pointer(s) of the display.

Most of the input device handling has been factored out into the separate GdkDeviceManager object. Every display has a device manager, which you can obtain using gdk_display_get_device_manager().

The DisplayManagerProtocol protocol exposes the methods and properties of an underlying GdkDisplayManager 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 DisplayManager. Alternatively, use DisplayManagerRef as a lighweight, unowned reference if you already have an instance you just want to use.

The purpose of the GdkDisplayManager singleton object is to offer notification when displays appear or disappear or the default display changes.

You can use gdk_display_manager_get() to obtain the GdkDisplayManager singleton, but that should be rarely necessary. Typically, initializing GTK+ opens a display that you can work with without ever accessing the GdkDisplayManager.

The GDK library can be built with support for multiple backends. The GdkDisplayManager object determines which backend is used at runtime.

When writing backend-specific code that is supposed to work with multiple GDK backends, you have to consider both compile time and runtime. At compile time, use the GDK_WINDOWING_X11, GDK_WINDOWING_WIN32 macros, etc. to find out which backends are present in the GDK library you are building your application against. At runtime, use type-check macros like GDK_IS_X11_DISPLAY() to find out which backend is in use:

Backend-specific code ##

(C Language Example):

#ifdef GDK_WINDOWING_X11
  if (GDK_IS_X11_DISPLAY (display))
    {
      // make X11-specific calls here
    }
  else
#endif
#ifdef GDK_WINDOWING_QUARTZ
  if (GDK_IS_QUARTZ_DISPLAY (display))
    {
      // make Quartz-specific calls here
    }
  else
#endif
  g_error ("Unsupported GDK backend");

The DragContextProtocol protocol exposes the methods and properties of an underlying GdkDragContext 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 DragContext. Alternatively, use DragContextRef as a lighweight, unowned reference if you already have an instance you just want to use.

The DrawingContextProtocol protocol exposes the methods and properties of an underlying GdkDrawingContext 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 DrawingContext. Alternatively, use DrawingContextRef as a lighweight, unowned reference if you already have an instance you just want to use.

GdkDrawingContext is an object that represents the current drawing state of a GdkWindow.

It’s possible to use a GdkDrawingContext to draw on a GdkWindow via rendering API like Cairo or OpenGL.

A GdkDrawingContext can only be created by calling gdk_window_begin_draw_frame() and will be valid until a call to gdk_window_end_draw_frame().

GdkDrawingContext is available since GDK 3.22

The FrameClockProtocol protocol exposes the methods and properties of an underlying GdkFrameClock 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 FrameClock. Alternatively, use FrameClockRef as a lighweight, unowned reference if you already have an instance you just want to use.

A GdkFrameClock tells the application when to update and repaint a window. This may be synced to the vertical refresh rate of the monitor, for example. Even when the frame clock uses a simple timer rather than a hardware-based vertical sync, the frame clock helps because it ensures everything paints at the same time (reducing the total number of frames). The frame clock can also automatically stop painting when it knows the frames will not be visible, or scale back animation framerates.

GdkFrameClock is designed to be compatible with an OpenGL-based implementation or with mozRequestAnimationFrame in Firefox, for example.

A frame clock is idle until someone requests a frame with gdk_frame_clock_request_phase(). At some later point that makes sense for the synchronization being implemented, the clock will process a frame and emit signals for each phase that has been requested. (See the signals of the GdkFrameClock class for documentation of the phases. GDK_FRAME_CLOCK_PHASE_UPDATE and the GdkFrameClock::update signal are most interesting for application writers, and are used to update the animations, using the frame time given by gdk_frame_clock_get_frame_time().

The frame time is reported in microseconds and generally in the same timescale as g_get_monotonic_time(), however, it is not the same as g_get_monotonic_time(). The frame time does not advance during the time a frame is being painted, and outside of a frame, an attempt is made so that all calls to gdk_frame_clock_get_frame_time() that are called at a “similar” time get the same value. This means that if different animations are timed by looking at the difference in time between an initial value from gdk_frame_clock_get_frame_time() and the value inside the GdkFrameClock::update signal of the clock, they will stay exactly synchronized.

The DevicePadProtocol protocol exposes the methods and properties of an underlying GdkDevicePad 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 DevicePad. Alternatively, use DevicePadRef as a lighweight, unowned reference if you already have an instance you just want to use.

GdkDevicePad is an interface implemented by devices of type GDK_SOURCE_TABLET_PAD, it allows querying the features provided by the pad device.

Tablet pads may contain one or more groups, each containing a subset of the buttons/rings/strips available. gdk_device_pad_get_n_groups() can be used to obtain the number of groups, gdk_device_pad_get_n_features() and gdk_device_pad_get_feature_group() can be combined to find out the number of buttons/rings/strips the device has, and how are they grouped.

Each of those groups have different modes, which may be used to map each individual pad feature to multiple actions. Only one mode is effective (current) for each given group, different groups may have different current modes. The number of available modes in a group can be found out through gdk_device_pad_get_group_n_modes(), and the current mode for a given group will be notified through the GdkEventPadGroupMode event.

The DevicePadInterfaceProtocol protocol exposes the methods and properties of an underlying GdkDevicePadInterface 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 DevicePadInterface. Alternatively, use DevicePadInterfaceRef as a lighweight, unowned reference if you already have an instance you just want to use.

The DrawingContextClassProtocol protocol exposes the methods and properties of an underlying GdkDrawingContextClass 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 DrawingContextClass. Alternatively, use DrawingContextClassRef as a lighweight, unowned reference if you already have an instance you just want to use.

The EventAnyProtocol protocol exposes the methods and properties of an underlying GdkEventAny 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 EventAny. Alternatively, use EventAnyRef as a lighweight, unowned reference if you already have an instance you just want to use.

Contains the fields which are common to all event structs. Any event pointer can safely be cast to a pointer to a GdkEventAny to access these fields.

The EventButtonProtocol protocol exposes the methods and properties of an underlying GdkEventButton 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 EventButton. Alternatively, use EventButtonRef as a lighweight, unowned reference if you already have an instance you just want to use.

Used for button press and button release events. The type field will be one of GDK_BUTTON_PRESS, GDK_2BUTTON_PRESS, GDK_3BUTTON_PRESS or GDK_BUTTON_RELEASE,

Double and triple-clicks result in a sequence of events being received. For double-clicks the order of events will be:

• GDK_BUTTON_PRESS
• GDK_BUTTON_RELEASE
• GDK_BUTTON_PRESS
• GDK_2BUTTON_PRESS
• GDK_BUTTON_RELEASE

Note that the first click is received just like a normal button press, while the second click results in a GDK_2BUTTON_PRESS being received just after the GDK_BUTTON_PRESS.

Triple-clicks are very similar to double-clicks, except that GDK_3BUTTON_PRESS is inserted after the third click. The order of the events is:

• GDK_BUTTON_PRESS
• GDK_BUTTON_RELEASE
• GDK_BUTTON_PRESS
• GDK_2BUTTON_PRESS
• GDK_BUTTON_RELEASE
• GDK_BUTTON_PRESS
• GDK_3BUTTON_PRESS
• GDK_BUTTON_RELEASE

For a double click to occur, the second button press must occur within ¼ of a second of the first. For a triple click to occur, the third button press must also occur within ½ second of the first button press.

The EventConfigureProtocol protocol exposes the methods and properties of an underlying GdkEventConfigure 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 EventConfigure. Alternatively, use EventConfigureRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated when a window size or position has changed.

The EventCrossingProtocol protocol exposes the methods and properties of an underlying GdkEventCrossing 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 EventCrossing. Alternatively, use EventCrossingRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated when the pointer enters or leaves a window.

The EventDNDProtocol protocol exposes the methods and properties of an underlying GdkEventDND 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 EventDND. Alternatively, use EventDNDRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated during DND operations.

The EventExposeProtocol protocol exposes the methods and properties of an underlying GdkEventExpose 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 EventExpose. Alternatively, use EventExposeRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated when all or part of a window becomes visible and needs to be redrawn.

The EventFocusProtocol protocol exposes the methods and properties of an underlying GdkEventFocus 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 EventFocus. Alternatively, use EventFocusRef as a lighweight, unowned reference if you already have an instance you just want to use.

Describes a change of keyboard focus.

The EventGrabBrokenProtocol protocol exposes the methods and properties of an underlying GdkEventGrabBroken 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 EventGrabBroken. Alternatively, use EventGrabBrokenRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated when a pointer or keyboard grab is broken. On X11, this happens when the grab window becomes unviewable (i.e. it or one of its ancestors is unmapped), or if the same application grabs the pointer or keyboard again. Note that implicit grabs (which are initiated by button presses) can also cause GdkEventGrabBroken events.

The EventKeyProtocol protocol exposes the methods and properties of an underlying GdkEventKey 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 EventKey. Alternatively, use EventKeyRef as a lighweight, unowned reference if you already have an instance you just want to use.

Describes a key press or key release event.

The EventMotionProtocol protocol exposes the methods and properties of an underlying GdkEventMotion 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 EventMotion. Alternatively, use EventMotionRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated when the pointer moves.

The EventOwnerChangeProtocol protocol exposes the methods and properties of an underlying GdkEventOwnerChange 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 EventOwnerChange. Alternatively, use EventOwnerChangeRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated when the owner of a selection changes. On X11, this information is only available if the X server supports the XFIXES extension.

The EventPadAxisProtocol protocol exposes the methods and properties of an underlying GdkEventPadAxis 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 EventPadAxis. Alternatively, use EventPadAxisRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated during GDK_SOURCE_TABLET_PAD interaction with tactile sensors.

The EventPadButtonProtocol protocol exposes the methods and properties of an underlying GdkEventPadButton 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 EventPadButton. Alternatively, use EventPadButtonRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated during GDK_SOURCE_TABLET_PAD button presses and releases.

The EventPadGroupModeProtocol protocol exposes the methods and properties of an underlying GdkEventPadGroupMode 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 EventPadGroupMode. Alternatively, use EventPadGroupModeRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated during GDK_SOURCE_TABLET_PAD mode switches in a group.

The EventPropertyProtocol protocol exposes the methods and properties of an underlying GdkEventProperty 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 EventProperty. Alternatively, use EventPropertyRef as a lighweight, unowned reference if you already have an instance you just want to use.

Describes a property change on a window.

The EventProximityProtocol protocol exposes the methods and properties of an underlying GdkEventProximity 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 EventProximity. Alternatively, use EventProximityRef as a lighweight, unowned reference if you already have an instance you just want to use.

Proximity events are generated when using GDK’s wrapper for the XInput extension. The XInput extension is an add-on for standard X that allows you to use nonstandard devices such as graphics tablets. A proximity event indicates that the stylus has moved in or out of contact with the tablet, or perhaps that the user’s finger has moved in or out of contact with a touch screen.

This event type will be used pretty rarely. It only is important for XInput aware programs that are drawing their own cursor.

The EventScrollProtocol protocol exposes the methods and properties of an underlying GdkEventScroll 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 EventScroll. Alternatively, use EventScrollRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated from button presses for the buttons 4 to 7. Wheel mice are usually configured to generate button press events for buttons 4 and 5 when the wheel is turned.

Some GDK backends can also generate “smooth” scroll events, which can be recognized by the GDK_SCROLL_SMOOTH scroll direction. For these, the scroll deltas can be obtained with gdk_event_get_scroll_deltas().

The EventSelectionProtocol protocol exposes the methods and properties of an underlying GdkEventSelection 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 EventSelection. Alternatively, use EventSelectionRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated when a selection is requested or ownership of a selection is taken over by another client application.

The EventSequenceProtocol protocol exposes the methods and properties of an underlying GdkEventSequence 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 EventSequence. Alternatively, use EventSequenceRef as a lighweight, unowned reference if you already have an instance you just want to use.

The EventSettingProtocol protocol exposes the methods and properties of an underlying GdkEventSetting 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 EventSetting. Alternatively, use EventSettingRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated when a setting is modified.

The EventTouchProtocol protocol exposes the methods and properties of an underlying GdkEventTouch 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 EventTouch. Alternatively, use EventTouchRef as a lighweight, unowned reference if you already have an instance you just want to use.

Used for touch events. type field will be one of GDK_TOUCH_BEGIN, GDK_TOUCH_UPDATE, GDK_TOUCH_END or GDK_TOUCH_CANCEL.

Touch events are grouped into sequences by means of the sequence field, which can also be obtained with gdk_event_get_event_sequence(). Each sequence begins with a GDK_TOUCH_BEGIN event, followed by any number of GDK_TOUCH_UPDATE events, and ends with a GDK_TOUCH_END (or GDK_TOUCH_CANCEL) event. With multitouch devices, there may be several active sequences at the same time.

The EventTouchpadPinchProtocol protocol exposes the methods and properties of an underlying GdkEventTouchpadPinch 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 EventTouchpadPinch. Alternatively, use EventTouchpadPinchRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated during touchpad swipe gestures.

The EventTouchpadSwipeProtocol protocol exposes the methods and properties of an underlying GdkEventTouchpadSwipe 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 EventTouchpadSwipe. Alternatively, use EventTouchpadSwipeRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated during touchpad swipe gestures.

The EventVisibilityProtocol protocol exposes the methods and properties of an underlying GdkEventVisibility 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 EventVisibility. Alternatively, use EventVisibilityRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated when the window visibility status has changed.

The EventWindowStateProtocol protocol exposes the methods and properties of an underlying GdkEventWindowState 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 EventWindowState. Alternatively, use EventWindowStateRef as a lighweight, unowned reference if you already have an instance you just want to use.

Generated when the state of a toplevel window changes.

The FrameClockClassProtocol protocol exposes the methods and properties of an underlying GdkFrameClockClass 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 FrameClockClass. Alternatively, use FrameClockClassRef as a lighweight, unowned reference if you already have an instance you just want to use.

The FrameTimingsProtocol protocol exposes the methods and properties of an underlying GdkFrameTimings 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 FrameTimings. Alternatively, use FrameTimingsRef as a lighweight, unowned reference if you already have an instance you just want to use.

A GdkFrameTimings object holds timing information for a single frame of the application’s displays. To retrieve GdkFrameTimings objects, use gdk_frame_clock_get_timings() or gdk_frame_clock_get_current_timings(). The information in GdkFrameTimings is useful for precise synchronization of video with the event or audio streams, and for measuring quality metrics for the application’s display, such as latency and jitter.

The GeometryProtocol protocol exposes the methods and properties of an underlying GdkGeometry 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 Geometry. Alternatively, use GeometryRef as a lighweight, unowned reference if you already have an instance you just want to use.

The GdkGeometry struct gives the window manager information about a window’s geometry constraints. Normally you would set these on the GTK+ level using gtk_window_set_geometry_hints(). GtkWindow then sets the hints on the GdkWindow it creates.

gdk_window_set_geometry_hints() expects the hints to be fully valid already and simply passes them to the window manager; in contrast, gtk_window_set_geometry_hints() performs some interpretation. For example, GtkWindow will apply the hints to the geometry widget instead of the toplevel window, if you set a geometry widget. Also, the min_width/min_height/max_width/max_height fields may be set to -1, and GtkWindow will substitute the size request of the window or geometry widget. If the minimum size hint is not provided, GtkWindow will use its requisition as the minimum size. If the minimum size is provided and a geometry widget is set, GtkWindow will take the minimum size as the minimum size of the geometry widget rather than the entire window. The base size is treated similarly.

The canonical use-case for gtk_window_set_geometry_hints() is to get a terminal widget to resize properly. Here, the terminal text area should be the geometry widget; GtkWindow will then automatically set the base size to the size of other widgets in the terminal window, such as the menubar and scrollbar. Then, the width_inc and height_inc fields should be set to the size of one character in the terminal. Finally, the base size should be set to the size of one character. The net effect is that the minimum size of the terminal will have a 1x1 character terminal area, and only terminal sizes on the “character grid” will be allowed.

Here’s an example of how the terminal example would be implemented, assuming a terminal area widget called “terminal” and a toplevel window “toplevel”:

(C Language Example):

    GdkGeometry hints;

    hints.base_width = terminal->char_width;
        hints.base_height = terminal->char_height;
        hints.min_width = terminal->char_width;
        hints.min_height = terminal->char_height;
        hints.width_inc = terminal->char_width;
        hints.height_inc = terminal->char_height;

 gtk_window_set_geometry_hints (GTK_WINDOW (toplevel),
                                GTK_WIDGET (terminal),
                                &hints,
                                GDK_HINT_RESIZE_INC |
                                GDK_HINT_MIN_SIZE |
                                GDK_HINT_BASE_SIZE);

The other useful fields are the min_aspect and max_aspect fields; these contain a width/height ratio as a floating point number. If a geometry widget is set, the aspect applies to the geometry widget rather than the entire window. The most common use of these hints is probably to set min_aspect and max_aspect to the same value, thus forcing the window to keep a constant aspect ratio.

The GLContextProtocol protocol exposes the methods and properties of an underlying GdkGLContext 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 GLContext. Alternatively, use GLContextRef as a lighweight, unowned reference if you already have an instance you just want to use.

GdkGLContext is an object representing the platform-specific OpenGL drawing context.

GdkGLContexts are created for a GdkWindow using gdk_window_create_gl_context(), and the context will match the GdkVisual of the window.

A GdkGLContext is not tied to any particular normal framebuffer. For instance, it cannot draw to the GdkWindow back buffer. The GDK repaint system is in full control of the painting to that. Instead, you can create render buffers or textures and use gdk_cairo_draw_from_gl() in the draw function of your widget to draw them. Then GDK will handle the integration of your rendering with that of other widgets.

Support for GdkGLContext is platform-specific, context creation can fail, returning nil context.

A GdkGLContext has to be made “current” in order to start using it, otherwise any OpenGL call will be ignored.

Creating a new OpenGL context

In order to create a new GdkGLContext instance you need a GdkWindow, which you typically get during the realize call of a widget.

A GdkGLContext is not realized until either gdk_gl_context_make_current(), or until it is realized using gdk_gl_context_realize(). It is possible to specify details of the GL context like the OpenGL version to be used, or whether the GL context should have extra state validation enabled after calling gdk_window_create_gl_context() by calling gdk_gl_context_realize(). If the realization fails you have the option to change the settings of the GdkGLContext and try again.

Using a GdkGLContext

You will need to make the GdkGLContext the current context before issuing OpenGL calls; the system sends OpenGL commands to whichever context is current. It is possible to have multiple contexts, so you always need to ensure that the one which you want to draw with is the current one before issuing commands:

(C Language Example):

  gdk_gl_context_make_current (context);

You can now perform your drawing using OpenGL commands.

You can check which GdkGLContext is the current one by using gdk_gl_context_get_current(); you can also unset any GdkGLContext that is currently set by calling gdk_gl_context_clear_current().

The KeymapProtocol protocol exposes the methods and properties of an underlying GdkKeymap 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 Keymap. Alternatively, use KeymapRef as a lighweight, unowned reference if you already have an instance you just want to use.

A GdkKeymap defines the translation from keyboard state (including a hardware key, a modifier mask, and active keyboard group) to a keyval. This translation has two phases. The first phase is to determine the effective keyboard group and level for the keyboard state; the second phase is to look up the keycode/group/level triplet in the keymap and see what keyval it corresponds to.

The KeymapKeyProtocol protocol exposes the methods and properties of an underlying GdkKeymapKey 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 KeymapKey. Alternatively, use KeymapKeyRef as a lighweight, unowned reference if you already have an instance you just want to use.

A GdkKeymapKey is a hardware key that can be mapped to a keyval.

The MonitorClassProtocol protocol exposes the methods and properties of an underlying GdkMonitorClass 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 MonitorClass. Alternatively, use MonitorClassRef as a lighweight, unowned reference if you already have an instance you just want to use.

The MonitorProtocol protocol exposes the methods and properties of an underlying GdkMonitor 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 Monitor. Alternatively, use MonitorRef as a lighweight, unowned reference if you already have an instance you just want to use.

GdkMonitor objects represent the individual outputs that are associated with a GdkDisplay. GdkDisplay has APIs to enumerate monitors with gdk_display_get_n_monitors() and gdk_display_get_monitor(), and to find particular monitors with gdk_display_get_primary_monitor() or gdk_display_get_monitor_at_window().

GdkMonitor was introduced in GTK+ 3.22 and supersedes earlier APIs in GdkScreen to obtain monitor-related information.

The ScreenProtocol protocol exposes the methods and properties of an underlying GdkScreen 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 Screen. Alternatively, use ScreenRef as a lighweight, unowned reference if you already have an instance you just want to use.

GdkScreen objects are the GDK representation of the screen on which windows can be displayed and on which the pointer moves. X originally identified screens with physical screens, but nowadays it is more common to have a single GdkScreen which combines several physical monitors (see gdk_screen_get_n_monitors()).

GdkScreen is used throughout GDK and GTK+ to specify which screen the top level windows are to be displayed on. it is also used to query the screen specification and default settings such as the default visual (gdk_screen_get_system_visual()), the dimensions of the physical monitors (gdk_screen_get_monitor_geometry()), etc.

The PointProtocol protocol exposes the methods and properties of an underlying GdkPoint 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 Point. Alternatively, use PointRef as a lighweight, unowned reference if you already have an instance you just want to use.

Defines the x and y coordinates of a point.

The RGBAProtocol protocol exposes the methods and properties of an underlying GdkRGBA 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 RGBA. Alternatively, use RGBARef as a lighweight, unowned reference if you already have an instance you just want to use.

A GdkRGBA is used to represent a (possibly translucent) color, in a way that is compatible with cairo’s notion of color.

The RectangleProtocol protocol exposes the methods and properties of an underlying GdkRectangle 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 Rectangle. Alternatively, use RectangleRef as a lighweight, unowned reference if you already have an instance you just want to use.

Defines the position and size of a rectangle. It is identical to cairo_rectangle_int_t.

The TimeCoordProtocol protocol exposes the methods and properties of an underlying GdkTimeCoord 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 TimeCoord. Alternatively, use TimeCoordRef as a lighweight, unowned reference if you already have an instance you just want to use.

A GdkTimeCoord stores a single event in a motion history.

The SeatProtocol protocol exposes the methods and properties of an underlying GdkSeat 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 Seat. Alternatively, use SeatRef as a lighweight, unowned reference if you already have an instance you just want to use.

The GdkSeat object represents a collection of input devices that belong to a user.

The VisualProtocol protocol exposes the methods and properties of an underlying GdkVisual 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 Visual. Alternatively, use VisualRef as a lighweight, unowned reference if you already have an instance you just want to use.

A GdkVisual contains information about a particular visual.

The WindowProtocol protocol exposes the methods and properties of an underlying GdkWindow 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 Window. Alternatively, use WindowRef as a lighweight, unowned reference if you already have an instance you just want to use.

The WindowAttrProtocol protocol exposes the methods and properties of an underlying GdkWindowAttr 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 WindowAttr. Alternatively, use WindowAttrRef as a lighweight, unowned reference if you already have an instance you just want to use.

Attributes to use for a newly-created window.

The WindowClassProtocol protocol exposes the methods and properties of an underlying GdkWindowClass 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 WindowClass. Alternatively, use WindowClassRef as a lighweight, unowned reference if you already have an instance you just want to use.

The WindowRedirectProtocol protocol exposes the methods and properties of an underlying GdkWindowRedirect 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 WindowRedirect. Alternatively, use WindowRedirectRef as a lighweight, unowned reference if you already have an instance you just want to use.

The EventProtocol protocol exposes the methods and properties of an underlying GdkEvent 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 Event. Alternatively, use EventRef as a lighweight, unowned reference if you already have an instance you just want to use.

A GdkEvent contains a union of all of the event types, and allows access to the data fields in a number of ways.

The event type is always the first field in all of the event types, and can always be accessed with the following code, no matter what type of event it is: (C Language Example):

  GdkEvent *event;
  GdkEventType type;

  type = event->type;

To access other fields of the event, the pointer to the event can be cast to the appropriate event type, or the union member name can be used. For example if the event type is GDK_BUTTON_PRESS then the x coordinate of the button press can be accessed with: (C Language Example):

  GdkEvent *event;
  gdouble x;

  x = ((GdkEventButton*)event)->x;

or: (C Language Example):

  GdkEvent *event;
  gdouble x;

  x = event->button.x;