This mask was forgotten to update when the last 2 event masks were
added, probably because it looks like it's already maxed.

GDK_PAD_BUTTON*,RING and STRIP will be emitted respectively when
pad buttons, rings or strips are interacted with. Each of those
pad components belong to a group (a pad can contain several of
those), which may be in a given mode. All this information is
contained in the event.

GDK_PAD_GROUP_MODE is emitted when a group in the pad switches
mode, which will generally result in a different set of actions
being triggered from the same buttons/rings/strips in the group.

https://bugzilla.gnome.org/show_bug.cgi?id=770026

Pavel Grunt authored Jun 02, 2016 and Matthias Clasen committed Jun 03, 2016

Mention in documentation that it is available since 3.16

https://bugzilla.gnome.org/show_bug.cgi?id=767165

These axes mmay or may not be present, best to ignore them.

This reverts 54fa65f5,
5190d010, and
a6e4de28.

https://bugzilla.gnome.org/show_bug.cgi?id=756579

https://bugzilla.gnome.org/show_bug.cgi?id=759309

Users will need to manually select on this in order to receive gesture
events.

https://bugzilla.gnome.org/show_bug.cgi?id=748833

Also try and clarify a few things about event propagation. Move
input-handling.xml into gtk-doc’s expand_content_files variable so it
automatically links to widget documentation. Add links from
gtk_widget_add_events() and friends to the new documentation.

https://bugzilla.gnome.org/show_bug.cgi?id=744054

The existence of OpenGL implementations that do not provide the full
core profile compatibility because of reasons beyond the technical, like
llvmpipe not implementing floating point buffers, makes the existence of
GdkGLProfile and documenting the fact that we use core profiles a bit
harder.

Since we do not have any existing profile except the default, we can
remove the GdkGLProfile and its related API from GDK and GTK+, and sweep
the whole thing under the carpet, while we wait for an extension that
lets us ask for the most compatible profile possible.

https://bugzilla.gnome.org/show_bug.cgi?id=744407

When using GDK_GL_PROFILE_3_2_CORE, we are not only specifying that the
GDK should create a core profile; we are also specifying that the
minimum required version of OpenGL is set to 3.2.

We should also specify that the GDK_GL_PROFILE_DEFAULT profile is an
alias for GDK_GL_PROFILE_3_2_CORE.

We simply don't want to care about legacy OpenGL.

All supported platforms also have support for OpenGL ≥ 3.2; it would
complicate the internal code; and would force us to use legacy GL
contexts internally if the first context created by the user is a legacy
GL context, and disable creation of core-3.2 contexts after that.

We will need to fix all our code examples to use the Core 3.2 profile.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

That seems ... counterproductive.

Alexander Larsson authored Oct 09, 2014 and Matthias Clasen committed Oct 13, 2014

This adds the new type GdkGLContext that wraps an OpenGL context for a
particular native window. It also adds support for the gdk paint
machinery to use OpenGL to draw everything. As soon as anyone creates
a GL context for a native window we create a "paint context" for that
GdkWindow and switch to using GL for painting it.

This commit contains only an implementation for X11 (using GLX).

The way painting works is that all client gl contexts draw into
offscreen buffers rather than directly to the back buffer, and the
way something gets onto the window is by using gdk_cairo_draw_from_gl()
to draw part of that buffer onto the draw cairo context.

As a fallback (if we're doing redirected drawing or some effect like a
cairo_push_group()) we read back the gl buffer into memory and composite
using cairo. This means that GL rendering works in all cases, including
rendering to a PDF. However, this is not particularly fast.

In the *typical* case, where we're drawing directly to the window in
the regular paint loop we hit the fast path. The fast path uses opengl
to draw the buffer to the window back buffer, either by blitting or
texturing. Then we track the region that was drawn, and when the draw
ends we paint the normal cairo surface to the window (using
texture-from-pixmap in the X11 case, or texture from cairo image
otherwise) in the regions where there is no gl painted.

There are some complexities wrt layering of gl and cairo areas though:
* We track via gdk_window_mark_paint_from_clip() whenever gtk is
  painting over a region we previously rendered with opengl
  (flushed_region). This area (needs_blend_region) is blended
  rather than copied at the end of the frame.
* If we're drawing a gl texture with alpha we first copy the current
  cairo_surface inside the target region to the back buffer before
  we blend over it.

These two operations allow us full stacking of transparent gl and cairo
regions.

https://wiki.gnome.org/Design/OS/Typography

Advise against using GDK_POINTER_MOTION_HINT_MASK.
Add pointers to gdk_window_set_event_compression() to the documentation.

so mention the non deprecated gdk_device_grab as well

gcc has optimizations for include guards that only work
if they are outermost in the the header.
https://bugzilla.gnome.org/show_bug.cgi?id=689810

https://bugzilla.gnome.org/show_bug.cgi?id=571254

The things related to touch and smooth scrolling were 3.4 additions,
so mark them as such.

https://bugzilla.gnome.org/show_bug.cgi?id=676329

Carlos Garnacho authored Jan 24, 2012 and Matthias Clasen committed Mar 01, 2012

By setting this event, a GdkWindow will receive scroll events
that provide delta values.

Carlos Garnacho authored Feb 28, 2011 and Matthias Clasen committed Mar 01, 2012

This commit introduces GDK_TOUCH_BEGIN/UPDATE/END/CANCEL
and a separate GdkEventTouch struct that they use. This
is closer to the touch event API of other platforms and
matches the xi2 events closely, too.

Michael Natterer authored Nov 18, 2011 and Michael Natterer committed Nov 18, 2011

Add GDK_MODIFIER_INTENT_SHIFT_GROUP to enum GdkModifierIntent
and handle it in gdk_keymap_get_modifier_mask(). Add an X11
impl of the method and return keymap_x11->group_switch_mask.
Return 0 from the default impl because we don't know.

Michael Natterer authored Sep 27, 2011 and Michael Natterer committed Sep 27, 2011

Add enum GdkModifierIntent which identifies use cases for modifier masks
and GdkKeyMap::get_modifier_mask(). Add a default implementation which returns
what is currently hardcoded all over GTK+, and an implementation in the
quartz backend. Also add gtk_widget_get_modifier_mask() which simplifies
things by doing widget->display->keymap->get_modifier_mask().

XKB and GDK both add "internal" bits to GdkModifierType.  In C,
this typically doesn't cause problems as bitfields are just integers,
and there's no validation.  However for bindings, it's normal to
convert enumerations to "native" enumeration types, which don't
support unknown bits.  See bug 597292.

https://bugzilla.gnome.org/show_bug.cgi?id=634994

Also get rid of the GDK_NATIVE_WINDOW_POINTER define.

And, since we've decided to keep the structs private, there is
no point in having the standard GObject clas macros anymore either.