2017-08-05 13:34:39 +00:00
|
|
|
|
/* GDK - The GIMP Drawing Kit
|
|
|
|
|
|
* Copyright (C) 1995-1997 Peter Mattis, Spencer Kimball and Josh MacDonald
|
|
|
|
|
|
*
|
|
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
|
|
* version 2 of the License, or (at your option) any later version.
|
|
|
|
|
|
*
|
|
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
|
|
*
|
|
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
|
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
|
* Modified by the GTK+ Team and others 1997-2000. See the AUTHORS
|
|
|
|
|
|
* file for a list of people on the GTK+ Team. See the ChangeLog
|
|
|
|
|
|
* files for a list of changes. These files are distributed with
|
|
|
|
|
|
* GTK+ at ftp://ftp.gtk.org/pub/gtk/.
|
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
#ifndef __GDK_EVENTS_PRIVATE_H__
|
|
|
|
|
|
#define __GDK_EVENTS_PRIVATE_H__
|
|
|
|
|
|
|
|
|
|
|
|
#include <gdk/gdktypes.h>
|
2018-07-02 11:39:09 +00:00
|
|
|
|
#include <gdk/gdkdrag.h>
|
2017-08-05 13:34:39 +00:00
|
|
|
|
#include <gdk/gdkdevice.h>
|
|
|
|
|
|
#include <gdk/gdkdevicetool.h>
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
G_BEGIN_DECLS
|
2020-02-21 02:22:16 +00:00
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
#define GDK_EVENT_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), GDK_TYPE_EVENT, GdkEventClass))
|
2020-02-21 02:22:16 +00:00
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
typedef struct _GdkEventClass GdkEventClass;
|
|
|
|
|
|
|
|
|
|
|
|
/*< private >
|
|
|
|
|
|
* GdkEvent:
|
|
|
|
|
|
* @ref_count: the reference count of the event
|
|
|
|
|
|
* @event_type: the specialized event type
|
|
|
|
|
|
* @surface: the surface of the event
|
|
|
|
|
|
* @device: the device of the event
|
|
|
|
|
|
* @time: a serial identifier of the event that can be used to order
|
|
|
|
|
|
* two events
|
|
|
|
|
|
* @flags: event flags
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* The abstract type for all windowing system events.
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*/
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkEvent
|
2017-08-05 13:34:39 +00:00
|
|
|
|
{
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GTypeInstance parent_instance;
|
|
|
|
|
|
|
|
|
|
|
|
grefcount ref_count;
|
|
|
|
|
|
|
|
|
|
|
|
/* Specialised event type */
|
|
|
|
|
|
GdkEventType event_type;
|
|
|
|
|
|
|
|
|
|
|
|
/* The surface of the event */
|
2018-03-20 14:14:10 +00:00
|
|
|
|
GdkSurface *surface;
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
|
|
|
|
|
|
/* The devices associated to the event */
|
2017-10-11 06:42:41 +00:00
|
|
|
|
GdkDevice *device;
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
|
|
|
|
|
|
guint32 time;
|
|
|
|
|
|
guint16 flags;
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/*< private >
|
|
|
|
|
|
* GdkEventClass:
|
|
|
|
|
|
* @finalize: a function called when the last reference held on an event is
|
|
|
|
|
|
* released; implementations of GdkEvent must chain up to the parent class
|
|
|
|
|
|
*
|
|
|
|
|
|
* The base class for events.
|
|
|
|
|
|
*/
|
|
|
|
|
|
struct _GdkEventClass
|
|
|
|
|
|
{
|
|
|
|
|
|
GTypeClass parent_class;
|
|
|
|
|
|
|
|
|
|
|
|
void (* finalize) (GdkEvent *event);
|
|
|
|
|
|
|
|
|
|
|
|
GdkModifierType (* get_state) (GdkEvent *event);
|
|
|
|
|
|
gboolean (* get_position) (GdkEvent *event,
|
|
|
|
|
|
double *x,
|
|
|
|
|
|
double *y);
|
|
|
|
|
|
GdkEventSequence * (* get_sequence) (GdkEvent *event);
|
|
|
|
|
|
GdkDeviceTool * (* get_tool) (GdkEvent *event);
|
|
|
|
|
|
gboolean (* get_axes) (GdkEvent *event,
|
|
|
|
|
|
double **axes,
|
|
|
|
|
|
guint *n_axes);
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
|
* GdkDeleteEvent:
|
|
|
|
|
|
*
|
|
|
|
|
|
* Generated when a surface is deleted.
|
|
|
|
|
|
*/
|
|
|
|
|
|
struct _GdkDeleteEvent
|
|
|
|
|
|
{
|
|
|
|
|
|
GdkEvent parent_instance;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
2017-12-26 15:30:50 +00:00
|
|
|
|
/*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* GdkMotionEvent:
|
|
|
|
|
|
* @state: (type GdkModifierType): a bit-mask representing the state of
|
|
|
|
|
|
* the modifier keys (e.g. Control, Shift and Alt) set during the motion
|
2021-11-07 17:14:15 +00:00
|
|
|
|
* event. See [flags@Gdk.ModifierType]
|
2018-03-20 14:14:10 +00:00
|
|
|
|
* @x: the x coordinate of the pointer relative to the surface.
|
|
|
|
|
|
* @y: the y coordinate of the pointer relative to the surface.
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @axes: @x, @y translated to the axes of @device, or %NULL if @device is
|
|
|
|
|
|
* the mouse.
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* @history: (element-type GdkTimeCoord): a list of time and coordinates
|
|
|
|
|
|
* for other motion events that were compressed before delivering the
|
|
|
|
|
|
* current event
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*
|
|
|
|
|
|
* Generated when the pointer moves.
|
|
|
|
|
|
*/
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkMotionEvent
|
2017-08-05 13:34:39 +00:00
|
|
|
|
{
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent parent_instance;
|
|
|
|
|
|
|
2020-02-18 04:08:44 +00:00
|
|
|
|
GdkModifierType state;
|
2020-02-18 03:20:01 +00:00
|
|
|
|
double x;
|
|
|
|
|
|
double y;
|
|
|
|
|
|
double *axes;
|
2017-10-11 06:42:41 +00:00
|
|
|
|
GdkDeviceTool *tool;
|
2020-04-25 15:50:11 +00:00
|
|
|
|
GArray *history; /* <GdkTimeCoord> */
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
2017-12-26 15:30:50 +00:00
|
|
|
|
/*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* GdkButtonEvent:
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @state: (type GdkModifierType): a bit-mask representing the state of
|
|
|
|
|
|
* the modifier keys (e.g. Control, Shift and Alt) and the pointer
|
2021-11-07 17:14:15 +00:00
|
|
|
|
* buttons. See [flags@Gdk.ModifierType]
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @button: the button which was pressed or released, numbered from 1 to 5.
|
|
|
|
|
|
* Normally button 1 is the left mouse button, 2 is the middle button,
|
|
|
|
|
|
* and 3 is the right button. On 2-button mice, the middle button can
|
|
|
|
|
|
* often be simulated by pressing both mouse buttons together.
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* @x: the x coordinate of the pointer relative to the surface.
|
|
|
|
|
|
* @y: the y coordinate of the pointer relative to the surface.
|
|
|
|
|
|
* @axes: @x, @y translated to the axes of @device, or %NULL if @device is
|
|
|
|
|
|
* the mouse.
|
2021-05-20 03:39:18 +00:00
|
|
|
|
* @tool: a `GdkDeviceTool`
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*
|
|
|
|
|
|
* Used for button press and button release events. The
|
2017-09-15 15:34:06 +00:00
|
|
|
|
* @type field will be one of %GDK_BUTTON_PRESS or %GDK_BUTTON_RELEASE,
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*/
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkButtonEvent
|
2017-08-05 13:34:39 +00:00
|
|
|
|
{
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent parent_instance;
|
|
|
|
|
|
|
2020-02-18 04:08:44 +00:00
|
|
|
|
GdkModifierType state;
|
|
|
|
|
|
guint button;
|
2020-02-18 03:20:01 +00:00
|
|
|
|
double x;
|
|
|
|
|
|
double y;
|
|
|
|
|
|
double *axes;
|
2017-10-11 06:42:41 +00:00
|
|
|
|
GdkDeviceTool *tool;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
2017-12-26 15:30:50 +00:00
|
|
|
|
/*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* GdkTouchEvent:
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @state: (type GdkModifierType): a bit-mask representing the state of
|
|
|
|
|
|
* the modifier keys (e.g. Control, Shift and Alt) and the pointer
|
2021-11-07 17:14:15 +00:00
|
|
|
|
* buttons. See [flags@Gdk.ModifierType]
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* @x: the x coordinate of the pointer relative to the surface
|
|
|
|
|
|
* @y: the y coordinate of the pointer relative to the surface
|
|
|
|
|
|
* @axes: @x, @y translated to the axes of the event's device, or %NULL
|
|
|
|
|
|
* if @device is the mouse
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @sequence: the event sequence that the event belongs to
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* @emulated: whether the event is the result of a pointer emulation
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*
|
|
|
|
|
|
* 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.
|
|
|
|
|
|
*/
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkTouchEvent
|
2017-08-05 13:34:39 +00:00
|
|
|
|
{
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent parent_instance;
|
|
|
|
|
|
|
2020-02-18 04:08:44 +00:00
|
|
|
|
GdkModifierType state;
|
2020-02-18 03:20:01 +00:00
|
|
|
|
double x;
|
|
|
|
|
|
double y;
|
|
|
|
|
|
double *axes;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
GdkEventSequence *sequence;
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
gboolean touch_emulating;
|
|
|
|
|
|
gboolean pointer_emulated;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
2017-12-26 15:30:50 +00:00
|
|
|
|
/*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* GdkScrollEvent:
|
2018-03-20 14:14:10 +00:00
|
|
|
|
* @x: the x coordinate of the pointer relative to the surface.
|
|
|
|
|
|
* @y: the y coordinate of the pointer relative to the surface.
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @state: (type GdkModifierType): a bit-mask representing the state of
|
|
|
|
|
|
* the modifier keys (e.g. Control, Shift and Alt) and the pointer
|
2021-11-07 17:14:15 +00:00
|
|
|
|
* buttons. See [flags@Gdk.ModifierType]
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @direction: the direction to scroll to (one of %GDK_SCROLL_UP,
|
|
|
|
|
|
* %GDK_SCROLL_DOWN, %GDK_SCROLL_LEFT, %GDK_SCROLL_RIGHT or
|
|
|
|
|
|
* %GDK_SCROLL_SMOOTH).
|
|
|
|
|
|
* @delta_x: the x coordinate of the scroll delta
|
|
|
|
|
|
* @delta_y: the y coordinate of the scroll delta
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* @pointer_emulated: whether the scroll event was the result of
|
|
|
|
|
|
* a pointer emulation
|
2021-05-20 03:39:18 +00:00
|
|
|
|
* @tool: a `GdkDeviceTool`
|
2021-12-15 04:42:14 +00:00
|
|
|
|
* @history: (element-type GdkTimeCoord): array of times and deltas
|
2020-06-09 00:29:38 +00:00
|
|
|
|
* for other scroll events that were compressed before delivering the
|
|
|
|
|
|
* current event
|
2022-02-21 15:22:57 +00:00
|
|
|
|
* @unit: The scroll unit in which delta_x and delta_y are represented.
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*
|
|
|
|
|
|
* 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().
|
|
|
|
|
|
*/
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkScrollEvent
|
2017-08-05 13:34:39 +00:00
|
|
|
|
{
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent parent_instance;
|
|
|
|
|
|
|
2020-02-18 03:20:01 +00:00
|
|
|
|
GdkModifierType state;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
GdkScrollDirection direction;
|
2020-02-18 03:20:01 +00:00
|
|
|
|
double delta_x;
|
|
|
|
|
|
double delta_y;
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
gboolean pointer_emulated;
|
|
|
|
|
|
gboolean is_stop;
|
2020-02-14 21:46:43 +00:00
|
|
|
|
GdkDeviceTool *tool;
|
2021-12-15 04:42:14 +00:00
|
|
|
|
GArray *history; /* <GdkTimeCoord> */
|
2022-02-21 15:22:57 +00:00
|
|
|
|
GdkScrollUnit unit;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
/*
|
|
|
|
|
|
* GdkTranslatedKey:
|
|
|
|
|
|
* @keyval: the translated key symbol
|
|
|
|
|
|
* @consumed: the consumed modifiers
|
|
|
|
|
|
* @layout: the keyboard layout
|
|
|
|
|
|
* @level: the layout level
|
|
|
|
|
|
*
|
|
|
|
|
|
* Describes a translated key code.
|
|
|
|
|
|
*/
|
2020-04-05 18:40:55 +00:00
|
|
|
|
typedef struct {
|
|
|
|
|
|
guint keyval;
|
|
|
|
|
|
GdkModifierType consumed;
|
|
|
|
|
|
guint layout;
|
|
|
|
|
|
guint level;
|
|
|
|
|
|
} GdkTranslatedKey;
|
|
|
|
|
|
|
2017-12-26 15:30:50 +00:00
|
|
|
|
/*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* GdkKeyEvent:
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @state: (type GdkModifierType): a bit-mask representing the state of
|
|
|
|
|
|
* the modifier keys (e.g. Control, Shift and Alt) and the pointer
|
2021-11-07 17:14:15 +00:00
|
|
|
|
* buttons. See [flags@Gdk.ModifierType]
|
2020-04-05 18:40:55 +00:00
|
|
|
|
* @keycode: the raw code of the key that was pressed or released.
|
|
|
|
|
|
* @translated: the result of translating @keycode. First with the full
|
|
|
|
|
|
* @state, then while ignoring Caps Lock.
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*
|
|
|
|
|
|
* Describes a key press or key release event.
|
|
|
|
|
|
*/
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkKeyEvent
|
2017-08-05 13:34:39 +00:00
|
|
|
|
{
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent parent_instance;
|
|
|
|
|
|
|
2020-02-18 03:20:01 +00:00
|
|
|
|
GdkModifierType state;
|
2020-04-05 18:40:55 +00:00
|
|
|
|
guint32 keycode;
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
gboolean key_is_modifier;
|
2020-04-05 18:40:55 +00:00
|
|
|
|
GdkTranslatedKey translated[2];
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
2017-12-26 15:30:50 +00:00
|
|
|
|
/*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* GdkCrossingEvent:
|
|
|
|
|
|
* @state: (type GdkModifierType): a bit-mask representing the state of
|
|
|
|
|
|
* the modifier keys (e.g. Control, Shift and Alt) and the pointer
|
2021-11-07 17:14:15 +00:00
|
|
|
|
* buttons. See [flags@Gdk.ModifierType]
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @mode: the crossing mode (%GDK_CROSSING_NORMAL, %GDK_CROSSING_GRAB,
|
|
|
|
|
|
* %GDK_CROSSING_UNGRAB, %GDK_CROSSING_GTK_GRAB, %GDK_CROSSING_GTK_UNGRAB or
|
|
|
|
|
|
* %GDK_CROSSING_STATE_CHANGED). %GDK_CROSSING_GTK_GRAB, %GDK_CROSSING_GTK_UNGRAB,
|
|
|
|
|
|
* and %GDK_CROSSING_STATE_CHANGED were added in 2.14 and are always synthesized,
|
|
|
|
|
|
* never native.
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* @x: the x coordinate of the pointer relative to the surface.
|
|
|
|
|
|
* @y: the y coordinate of the pointer relative to the surface.
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @detail: the kind of crossing that happened (%GDK_NOTIFY_INFERIOR,
|
|
|
|
|
|
* %GDK_NOTIFY_ANCESTOR, %GDK_NOTIFY_VIRTUAL, %GDK_NOTIFY_NONLINEAR or
|
|
|
|
|
|
* %GDK_NOTIFY_NONLINEAR_VIRTUAL).
|
2018-03-20 14:14:10 +00:00
|
|
|
|
* @focus: %TRUE if @surface is the focus surface or an inferior.
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* @child_surface: the surface that was entered or left.
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*
|
2018-03-20 14:14:10 +00:00
|
|
|
|
* Generated when the pointer enters or leaves a surface.
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*/
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkCrossingEvent
|
2017-08-05 13:34:39 +00:00
|
|
|
|
{
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent parent_instance;
|
|
|
|
|
|
|
2020-02-18 04:08:44 +00:00
|
|
|
|
GdkModifierType state;
|
|
|
|
|
|
GdkCrossingMode mode;
|
2020-02-18 03:20:01 +00:00
|
|
|
|
double x;
|
|
|
|
|
|
double y;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
GdkNotifyType detail;
|
|
|
|
|
|
gboolean focus;
|
2020-02-18 04:08:44 +00:00
|
|
|
|
GdkSurface *child_surface;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
2017-12-26 15:30:50 +00:00
|
|
|
|
/*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* GdkFocusEvent:
|
2018-03-20 14:14:10 +00:00
|
|
|
|
* @in: %TRUE if the surface has gained the keyboard focus, %FALSE if
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* it has lost the focus.
|
2019-03-06 21:55:27 +00:00
|
|
|
|
* @mode: the crossing mode
|
|
|
|
|
|
* @detail: the kind of crossing that happened
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*
|
|
|
|
|
|
* Describes a change of keyboard focus.
|
|
|
|
|
|
*/
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkFocusEvent
|
2017-08-05 13:34:39 +00:00
|
|
|
|
{
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent parent_instance;
|
|
|
|
|
|
|
|
|
|
|
|
gboolean focus_in;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
2017-12-26 15:30:50 +00:00
|
|
|
|
/*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* GdkProximityEvent:
|
2021-05-20 03:39:18 +00:00
|
|
|
|
* @tool: the `GdkDeviceTool` associated to the event
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* A proximity event indicates that a tool of a graphic tablet, or similar
|
|
|
|
|
|
* devices that report proximity, 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.
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*/
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkProximityEvent
|
2017-08-05 13:34:39 +00:00
|
|
|
|
{
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent parent_instance;
|
|
|
|
|
|
|
2020-02-14 21:46:43 +00:00
|
|
|
|
GdkDeviceTool *tool;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
2017-12-26 15:30:50 +00:00
|
|
|
|
/*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* GdkGrabBrokenEvent:
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @keyboard: %TRUE if a keyboard grab was broken, %FALSE if a pointer
|
|
|
|
|
|
* grab was broken
|
|
|
|
|
|
* @implicit: %TRUE if the broken grab was implicit
|
2018-03-20 14:14:10 +00:00
|
|
|
|
* @grab_surface: If this event is caused by another grab in the same
|
|
|
|
|
|
* application, @grab_surface contains the new grab surface. Otherwise
|
|
|
|
|
|
* @grab_surface is %NULL.
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*
|
|
|
|
|
|
* Generated when a pointer or keyboard grab is broken. On X11, this happens
|
2018-03-20 14:14:10 +00:00
|
|
|
|
* when the grab surface becomes unviewable (i.e. it or one of its ancestors
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* is unmapped), or if the same application grabs the pointer or keyboard
|
|
|
|
|
|
* again. Note that implicit grabs (which are initiated by button presses)
|
2021-05-20 03:39:18 +00:00
|
|
|
|
* can also cause `GdkGrabBrokenEvent` events.
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*/
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkGrabBrokenEvent
|
|
|
|
|
|
{
|
|
|
|
|
|
GdkEvent parent_instance;
|
|
|
|
|
|
|
2017-08-05 13:34:39 +00:00
|
|
|
|
gboolean keyboard;
|
|
|
|
|
|
gboolean implicit;
|
2018-03-20 14:14:10 +00:00
|
|
|
|
GdkSurface *grab_surface;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
2017-12-26 15:30:50 +00:00
|
|
|
|
/*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* GdkDNDEvent:
|
2021-05-20 03:39:18 +00:00
|
|
|
|
* @drop: the `GdkDrop` for the current DND operation.
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* @x: the X coordinate of the pointer
|
|
|
|
|
|
* @y: the Y coordinate of the pointer
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*
|
|
|
|
|
|
* Generated during DND operations.
|
|
|
|
|
|
*/
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkDNDEvent
|
|
|
|
|
|
{
|
|
|
|
|
|
GdkEvent parent_instance;
|
|
|
|
|
|
|
2018-05-29 18:49:41 +00:00
|
|
|
|
GdkDrop *drop;
|
2019-12-30 16:56:49 +00:00
|
|
|
|
double x;
|
|
|
|
|
|
double y;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
2017-12-26 15:30:50 +00:00
|
|
|
|
/*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* GdkTouchpadEvent:
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @state: (type GdkModifierType): a bit-mask representing the state of
|
|
|
|
|
|
* the modifier keys (e.g. Control, Shift and Alt) and the pointer
|
2021-11-07 17:14:15 +00:00
|
|
|
|
* buttons. See [flags@Gdk.ModifierType]
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* @phase: (type GdkTouchpadGesturePhase): the current phase of the gesture
|
|
|
|
|
|
* @n_fingers: The number of fingers triggering the pinch
|
|
|
|
|
|
* @time: the time of the event in milliseconds
|
|
|
|
|
|
* @x: The X coordinate of the pointer
|
|
|
|
|
|
* @y: The Y coordinate of the pointer
|
|
|
|
|
|
* @dx: Movement delta in the X axis of the swipe focal point
|
|
|
|
|
|
* @dy: Movement delta in the Y axis of the swipe focal point
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* @angle_delta: For pinch events, the angle change in radians, negative angles
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* denote counter-clockwise movements
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* @scale: For pinch events, the current scale, relative to that at the time of
|
2017-08-05 13:34:39 +00:00
|
|
|
|
* the corresponding %GDK_TOUCHPAD_GESTURE_PHASE_BEGIN event
|
|
|
|
|
|
*
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
* Generated during touchpad gestures.
|
2017-08-05 13:34:39 +00:00
|
|
|
|
*/
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkTouchpadEvent
|
|
|
|
|
|
{
|
|
|
|
|
|
GdkEvent parent_instance;
|
|
|
|
|
|
|
2021-12-16 01:11:51 +00:00
|
|
|
|
GdkEventSequence *sequence;
|
2020-02-18 04:08:44 +00:00
|
|
|
|
GdkModifierType state;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
gint8 phase;
|
|
|
|
|
|
gint8 n_fingers;
|
2020-02-18 03:20:01 +00:00
|
|
|
|
double x;
|
|
|
|
|
|
double y;
|
|
|
|
|
|
double dx;
|
|
|
|
|
|
double dy;
|
|
|
|
|
|
double angle_delta;
|
|
|
|
|
|
double scale;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
struct _GdkPadEvent
|
|
|
|
|
|
{
|
|
|
|
|
|
GdkEvent parent_instance;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
|
|
|
|
|
|
guint group;
|
|
|
|
|
|
guint mode;
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
guint button;
|
|
|
|
|
|
guint index;
|
2020-02-18 03:20:01 +00:00
|
|
|
|
double value;
|
2017-08-05 13:34:39 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
void gdk_event_init_types (void);
|
2017-08-05 13:34:39 +00:00
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_button_event_new (GdkEventType type,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkSurface *surface,
|
|
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
GdkDeviceTool *tool,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
GdkModifierType state,
|
|
|
|
|
|
guint button,
|
|
|
|
|
|
double x,
|
|
|
|
|
|
double y,
|
|
|
|
|
|
double *axes);
|
2020-04-25 15:50:11 +00:00
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_motion_event_new (GdkSurface *surface,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
GdkDeviceTool *tool,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
GdkModifierType state,
|
|
|
|
|
|
double x,
|
|
|
|
|
|
double y,
|
|
|
|
|
|
double *axes);
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_crossing_event_new (GdkEventType type,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkSurface *surface,
|
|
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
GdkModifierType state,
|
|
|
|
|
|
double x,
|
|
|
|
|
|
double y,
|
|
|
|
|
|
GdkCrossingMode mode,
|
|
|
|
|
|
GdkNotifyType notify);
|
2020-04-25 15:50:11 +00:00
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_proximity_event_new (GdkEventType type,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkSurface *surface,
|
|
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
GdkDeviceTool *tool,
|
|
|
|
|
|
guint32 time);
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_key_event_new (GdkEventType type,
|
2020-04-05 18:40:55 +00:00
|
|
|
|
GdkSurface *surface,
|
|
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
guint keycode,
|
|
|
|
|
|
GdkModifierType modifiers,
|
|
|
|
|
|
gboolean is_modifier,
|
|
|
|
|
|
GdkTranslatedKey *translated,
|
|
|
|
|
|
GdkTranslatedKey *no_lock);
|
2020-02-14 13:09:59 +00:00
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_focus_event_new (GdkSurface *surface,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
gboolean focus_in);
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_delete_event_new (GdkSurface *surface);
|
2020-02-14 13:09:59 +00:00
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_scroll_event_new (GdkSurface *surface,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
GdkDeviceTool *tool,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
GdkModifierType state,
|
|
|
|
|
|
double delta_x,
|
|
|
|
|
|
double delta_y,
|
2022-02-21 15:22:57 +00:00
|
|
|
|
gboolean is_stop,
|
|
|
|
|
|
GdkScrollUnit unit);
|
2020-02-14 13:09:59 +00:00
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_scroll_event_new_discrete (GdkSurface *surface,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
GdkDeviceTool *tool,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
GdkModifierType state,
|
|
|
|
|
|
GdkScrollDirection direction,
|
|
|
|
|
|
gboolean emulated);
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_touch_event_new (GdkEventType type,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkEventSequence *sequence,
|
|
|
|
|
|
GdkSurface *surface,
|
|
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
GdkModifierType state,
|
|
|
|
|
|
double x,
|
|
|
|
|
|
double y,
|
|
|
|
|
|
double *axes,
|
|
|
|
|
|
gboolean emulating);
|
2020-04-25 15:50:11 +00:00
|
|
|
|
|
2021-12-16 01:11:51 +00:00
|
|
|
|
GdkEvent * gdk_touchpad_event_new_swipe (GdkSurface *surface,
|
|
|
|
|
|
GdkEventSequence *sequence,
|
|
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
GdkModifierType state,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkTouchpadGesturePhase phase,
|
2021-12-16 01:11:51 +00:00
|
|
|
|
double x,
|
|
|
|
|
|
double y,
|
|
|
|
|
|
int n_fingers,
|
|
|
|
|
|
double dx,
|
|
|
|
|
|
double dy);
|
2020-02-14 13:09:59 +00:00
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_touchpad_event_new_pinch (GdkSurface *surface,
|
2021-12-16 01:11:51 +00:00
|
|
|
|
GdkEventSequence *sequence,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
GdkModifierType state,
|
|
|
|
|
|
GdkTouchpadGesturePhase phase,
|
|
|
|
|
|
double x,
|
|
|
|
|
|
double y,
|
|
|
|
|
|
int n_fingers,
|
|
|
|
|
|
double dx,
|
|
|
|
|
|
double dy,
|
|
|
|
|
|
double scale,
|
|
|
|
|
|
double angle_delta);
|
|
|
|
|
|
|
2021-06-27 09:49:24 +00:00
|
|
|
|
GdkEvent * gdk_touchpad_event_new_hold (GdkSurface *surface,
|
|
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
GdkModifierType state,
|
|
|
|
|
|
GdkTouchpadGesturePhase phase,
|
|
|
|
|
|
double x,
|
|
|
|
|
|
double y,
|
|
|
|
|
|
int n_fingers);
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_pad_event_new_ring (GdkSurface *surface,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
guint group,
|
|
|
|
|
|
guint index,
|
|
|
|
|
|
guint mode,
|
|
|
|
|
|
double value);
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_pad_event_new_strip (GdkSurface *surface,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
guint group,
|
|
|
|
|
|
guint index,
|
|
|
|
|
|
guint mode,
|
|
|
|
|
|
double value);
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_pad_event_new_button (GdkEventType type,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkSurface *surface,
|
|
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
guint group,
|
|
|
|
|
|
guint button,
|
|
|
|
|
|
guint mode);
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_pad_event_new_group_mode (GdkSurface *surface,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
guint group,
|
|
|
|
|
|
guint mode);
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_dnd_event_new (GdkEventType type,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkSurface *surface,
|
|
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
GdkDrop *drop,
|
|
|
|
|
|
guint32 time,
|
|
|
|
|
|
double x,
|
|
|
|
|
|
double y);
|
|
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
GdkEvent * gdk_grab_broken_event_new (GdkSurface *surface,
|
2020-02-14 13:09:59 +00:00
|
|
|
|
GdkDevice *device,
|
|
|
|
|
|
GdkSurface *grab_surface,
|
|
|
|
|
|
gboolean implicit);
|
|
|
|
|
|
|
2020-05-22 11:35:58 +00:00
|
|
|
|
GdkTranslatedKey * gdk_key_event_get_translated_key (GdkEvent *event,
|
|
|
|
|
|
gboolean no_lock);
|
|
|
|
|
|
|
2020-08-14 01:47:54 +00:00
|
|
|
|
typedef enum
|
|
|
|
|
|
{
|
|
|
|
|
|
/* Following flag is set for events on the event queue during
|
|
|
|
|
|
* translation and cleared afterwards.
|
|
|
|
|
|
*/
|
|
|
|
|
|
GDK_EVENT_PENDING = 1 << 0,
|
|
|
|
|
|
|
|
|
|
|
|
/* When we are ready to draw a frame, we pause event delivery,
|
|
|
|
|
|
* mark all events in the queue with this flag, and deliver
|
|
|
|
|
|
* only those events until we finish the frame.
|
|
|
|
|
|
*/
|
|
|
|
|
|
GDK_EVENT_FLUSHED = 1 << 2
|
|
|
|
|
|
} GdkEventFlags;
|
|
|
|
|
|
|
|
|
|
|
|
GdkEvent* _gdk_event_unqueue (GdkDisplay *display);
|
|
|
|
|
|
|
|
|
|
|
|
void _gdk_event_emit (GdkEvent *event);
|
|
|
|
|
|
GList* _gdk_event_queue_find_first (GdkDisplay *display);
|
|
|
|
|
|
void _gdk_event_queue_remove_link (GdkDisplay *display,
|
|
|
|
|
|
GList *node);
|
|
|
|
|
|
GList* _gdk_event_queue_append (GdkDisplay *display,
|
|
|
|
|
|
GdkEvent *event);
|
|
|
|
|
|
|
|
|
|
|
|
void _gdk_event_queue_handle_motion_compression (GdkDisplay *display);
|
|
|
|
|
|
void gdk_event_queue_handle_scroll_compression (GdkDisplay *display);
|
|
|
|
|
|
void _gdk_event_queue_flush (GdkDisplay *display);
|
|
|
|
|
|
|
2020-12-17 15:32:31 +00:00
|
|
|
|
double * gdk_event_dup_axes (GdkEvent *event);
|
|
|
|
|
|
|
2020-08-14 01:47:54 +00:00
|
|
|
|
|
Restructure the GdkEvent type hierarchy
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
2020-04-16 16:23:36 +00:00
|
|
|
|
G_END_DECLS
|
2019-01-17 16:02:49 +00:00
|
|
|
|
|
2017-08-05 13:34:39 +00:00
|
|
|
|
#endif /* __GDK_EVENTS_PRIVATE_H__ */
|
