gtk+-3.24.14 with quartz backend fails to compile on macOS when using
a case-sensitive file system. The cause for the compilation error is a
simple typo in line 26 of `gdk/quartz/gdkquartz-gtk-only.h`. The
AppKit framework is included there with `<Appkit/Appkit.h>` instead of
`<AppKit/AppKit.h>`, which is fixed with this commit.
References: https://trac.macports.org/ticket/60168
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2503
If NULL is returned, probably the client shouldn't advertise the
mimetype. Make it sure we forget entirely about the attempt to
cache this mimetype, as it'll be mistaken as pending otherwise.
Dropping this cached selection will in consequence close the fd
of all pending readers, which seems appropriate for NULL content.
https://gitlab.gnome.org/GNOME/gtk/issues/2456
The only way to have G_IO_ERROR_CANCELLED in the write callback
goes through having the array of pending writers already cleared.
It should not access the invalid AsyncWriteData and StoredSelection
in that case.
gdk_window_impl_quartz_release_context () can be called with a NULL CGContextRef. This causes CoreGraphics assertion failures when debugging a Gtk application in Xcode, as the code was blindly passing that NULL to CGContextRestoreGState () and CGContextSetAllowsAntialiasing (). Given that the matching pair of CGContextSaveGState () and CGContextSetAllowsAntialiasing () calls are already checking for a NULL CGContextRef, it seems reasonable to wrap these calls in a NULL check.
Cache separately the selection contents for each given window/selection/atom
combination, and keep the requestors separate for each of those.
This allows us to incrementally request multiple mimetypes, and dispatch
the requestors as soon as the data is up. This stored selection content is
cached until the selection owner changes, at which point all pending readers
could get their transfers cancelled, and the stored content for the selection
forgotten.
For a given OpenGL context, macOS in particular does not support enumeration / detection of OpenGL features that have been promoted to core OpenGL functionality. It is possible other drivers are the same. This change assumes support for GL_ARB_texture_non_power_of_two with OpenGL 2.0+, GL_ARB_texture_rectangle with OpenGL 3.1+ and GL_EXT_framebuffer_blit with OpenGL 3.0+. I failed to find definitive information on whether GL_GREMEDY_frame_terminator has been promoted to OpenGL core, or whether GL_ANGLE_framebuffer_blit or GL_EXT_unpack_subimage have been promoted to core in OpenGL ES. This change results in a significant GtkGLArea performance boost on macOS.
Closes#2428
When a device is added, there are two references to it by the device
manager, the initial one and the one used for the id_table. Removing a
device only removed the reference added by the id_table resulting in the
GdkDevice being leaked.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/1359
On Wayland, opening and closing a `GdkDisplay` generates a coupe of
warnings at runtime:
```
GLib-GObject-WARNING **:
invalid cast from 'GdkWindowImplWayland' to 'GdkWindow'
GLib-GObject-WARNING **:
invalid cast from 'GdkWaylandWindow' to 'GdkWindowImplWayland'
```
This is from `gdk_window_impl_wayland_finalize()` which tries to cast
the given GObject to a `GdkWindow` while it's a `GdkWindowImplWayland`.
Use the correct type casting of objects to avoid the warnings.
The sed -i flag is non-standard, and may not be available in all
implementations.
The meson build already requires wayland >= 1.14.91 and uses
private-code, so just do that in the autotools build as well.
Window scale can change at runtime. If cairo_surface is already
created for root window gdk_pixbuf_get_from_window will return
wrong image.
_gdk_x11_screen_set_window_scale already updates window_scale for
root window, update also cairo_surface device scale.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/1208
Also ensure that gdkquartz-gtk-only.h is included in distribution
tarballs.
Failing to include gdkquartz-gtk-only.h in gdkselection-quartz.c
caused the compiler to not set the extern storage class on the
functions, in turn causing them to be not exported by libgdk-3.0.dylib.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/32 again.
Otherwise the icon "jumps" to the cursor position with its top left when
the animation starts.
This is especially visible if the dragged item is big, like when dragging
mails in Thunderbird.
With some GL drivers, it may be the case that menus are not shown
correctly in fullscreen GL windows because DWM is deactivated in the
process.
Force WS_BORDER to be applied to the fullscreen GL window so that we have
a small 1px border when needed (by setting an envvar), so that DWM does
not get deactivated, hence enabling the menus to show. Also, when we
force WS_BORDER to be applied in this situation, we also deliberately
place the window just outside the top lefthand corner of the screen by
1px and make the window 1px larger than the screen size, so that we
effectively hide the 1px border from view.
Fixes issue #1702.
_gdk_win32_display_convert_selection() does not return anything,
it generates a selection notify event instead. Depending on how
successful it was, the event will have property=GDK_NONE or
property="GDK_SELECTION".
property="GDK_SELECTION" is the default return value for successful
cases, and it tells GTK to grab the data that GDK previously deposited
using selection_property_store().
The problem is that the clipboard branch of this function calls
open_clipboard_timeout(), which can't return anything meaningful (it's
normally a timeout function), and thus doesn't know whether the function
succeeded or failed. Due to my oversight, this resulted in GDK
generating two selection notification events - one from inside of
open_clipboard_timeout() (with the right property, if successful),
and one from the catch-all last line (always defaulting to "GDK_SELECTION").
This caused issue #2223, where GTK only expected exactly one
notification per request, and got confused because it was getting two.
I've looked at the code in open_clipboard_timeout(), and it seems to me
that it always generates a notification (a successful one or an
unsuccessful one). Thus the branch of the function that calls it
directly does not need to follow up with a catch-all notification and
can just return.
This seems to be fixing issue #2223, at least for me, but i'm not
entirely sure that this will not have any adverse side-effects.
Clipboard handling in GTK3 is a complicated mess.
Instead, use the standard library().
This is a meson best practice.
Fixes#2248.
Fixes -Ddefault_library=static not having any effect.
Cherry-Picked-From: bb9c07d8fe
It can be tricky to deal with both, so let's give an example of using
both gdk_event_get_scroll_direction() and gdk_event_get_scroll_deltas().
Closes: #2048
For page up/down events (Fn+up_arrow and Fn+down_arrow on macOS)
gtk_im_context_filter_keypress() currently returns TRUE when im-quartz is
used. This means these events get removed when this function is used
(happens e.g. with the Scintilla text editing library).
Adding scrollPageDown: and scrollPageUp: into GdkQuartzView seems to
resolve the issue as these seem to get called instead of the already
present pageUp: and pageDown:.
We are interested in changing the owner window, so the upper bits know
that it is not this client who owns the selection. We are still not
interested in unsetting the selection desktop-wide though, so only avoid
emitting the relevant events then.
The same reasonings than in commit 7a891eeb6d apply otherwise.
Use RemoveClipboardFormatListener() and AddClipboardFormatListener().
These APIs remove the need for us to maintain the integrity of the
clipboard chain, which turned out to be problematic for some reason
that is yet to be identified.
Fixes#2215Fixes#442
This should just be called by the upper layers (and result in
wl_data_device.set_selection, etc). We should not trigger this within
the backend otherwise.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/878
This should only be explicitly unset (face to the windowing) on
gdk_selection_owner_set() with a NULL window. Other circumstances
(eg. selection being taken over by another client) should just
trigger the SelectionClear event in GDK internally.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/878
The event may end up freed after delivery, ensure to keep the data we need
in order to emit the matching emulated crossed event matching a proximity
event.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2157
The code managing this accounting mixed seat and tablet output lists,
can't bode well. Fixes invalid reads on list elements, as there are
dangling pointers.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2157
