This mapping of stylus evdev input event codes into GDK button numbers
makes gdk/wayland inconsistent with gdk/x11, so depending on the backend
the same button middle-click pastes or right-click pops up menus.
Make the wayland backend consistent with X11, so that a GNOME wayland
session gets these buttons consistently mapped across all kinds of
clients.
(cherry-picked from commit e28ff79bec53ecd56885390ba4a66019cde598c6)
There is no need to include gdkquartz.h there,
which was making it impossible to include this header file
without also adding gdk/ as an include directory when compiling.
This patch moves the include to the only location where it is actually needed.
Copy what we do in GTK4: Check for GL >= 3.2 or GLES >= 3.0 or the
GL_ARB_sync extension.
Then store that info for a (private) gdk_gl_context_has_sync()
function.
And then check that function before using GLsync objects as introduced
by commit 9811485990.
Fixes#5749
These devices unfortunately didn't ever get a capability flag in
3.24 (fixed in GTK4). We are very far off into maintenance grounds that
it is not ideal to add new flag values, but we could however return
these devices if GDK_SEAT_CAPABILITY_ALL is being asked.
Do that, so it is possible to deal with pad devices, even if it's
not possible to query them specifically.
We've used to emit these in the GdkDeviceManager, but missed to do
this signal emission at the GdkSeat object level. In order to avoid
the double emission, trigger one from the other.
We were creating the pad device on wp_tablet_pad.done, but
at that time we do not know what tablet it is associated with,
thus we cannot get appropriate vid/pid/name properties for it.
To get that, we need to wait for the pad to enter a surface,
at that time we do know what tablet it is associated with, so
we can get better information about the device.
There are pads that may plausibly "change" tablet between
one .enter event and the next (e.g. Wacom Express Key Remote),
but this situation is highly unlikely. The pad devices created
are thus persistent until that situation happens.
Clarify that we zero out the widget coords and only keep its dimensions.
If we have no widget to fall-back to, memset to 0 the output @rect since
we return FALSE whether or not we have widget, so protect users from not
knowing if there was a widget and possibly accessing uninitialised ints.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/893#note_1766079
I observed the following nautilus crash below after trying to access an SMB
share and mistyping my password (it also happens if mounting the SMB share
fails for other reasons after entering a password). The crash happens when
the password entry window pops up the second time, in this code path, at
the 7th element of priv->user_widgets:
458 pw_dialog_anonymous_toggled (GtkWidget *widget,
459 GtkMountOperation *operation)
460 {
...
472 for (l = priv->user_widgets; l != NULL; l = l->next)
473 {
474 gtk_widget_set_sensitive (GTK_WIDGET (l->data), !priv->anonymous);
475 }
The broken element had l->data = 0xaaaaaaaaaaaa, which means the pointer had
been freed.
The broken list entries were at the of the list because when
gtk_mount_operation_ask_password_do_gtk() constucts the pop-up the 2nd time,
it prepends new widgets:
gtk_mount_operation_ask_password_do_gtk()
table_add_entry
operation->priv->user_widgets = g_list_prepend (operation->priv->user_widgets, entry);
The problem is that in pw_dialog_got_response(), the widget is destroyed,
which also destroys all child widgets, but the priv->user_widgets list is
neither freed nor set to NULL.
Fix it.
We may try to update the XRR outputs and Crtcs when they're changing in
the server, and so we may get BadRROutput that we're currently not
handling properly.
As per this, use traps and check whether we got errors, and if we did
let's ignore the current output.
It's not required to call init_randr13() again because if we got errors
it's very likely that there's a change coming that will be notified at
next iteration during which we'll repeat the init actions.
This commit fixes a performance issue on X11 systems making use of the gdk_cairo_draw_from_gl() function in regards
to drawing on an OpenGL surface in GTK/GDK. Specifically, this fix removes the slow X11 codepath that was used when
executing the gdk_cairo_draw_from_gl() function because it was completely uneeded. I tested the before and after on
Flutter and GTK apps making use of the OpenGL rendering and can confirm that there is no behaviour and visual
difference. This change is also specific to drawings that make use of textures. The render buffer code path has
been left completely unmodified.
Closes#4704
1. According to the UTF-8 spec, ASCII character's charcode is from
0 to 127 inclusively.
2. Any charcode which is greater than or equal to 128 will be
a multi-byte character.
1. The data with type of char is signed by default.
2. The byte value of UTF-8 is signless by default.
3. So, if a UTF-8 charcode is stored in a char array, we should cast the
type of its value from char to unsigned char.
check_dir_mtime() is called by ftw() and is given
the real stat struct, not its glib version (which may
or may not be the same as "struct stat").
This is irrelevant for MSVC (it has no ftw()) and
works correctly for MinGW-w64 (which declares stat
structures correctly). If mingw.org complains, add
a special ifdef for it later.
Otherwise the rastering gets messed up and popup windows get badly
truncated lengthwise on non-Retina monitors when there are both
Retina and non-Retina monitors.
