There is no way for custom Wayland surfaces to get configure events, so an
initial configure event should not be required to resize a custom surface.
Fixes#2578.
When we `Alt+Tab` away from a GTK application, it loses keyboard focus.
If we don't clear the modifiers, events from other devices that we
receive while unfocused will assume `Alt` is still pressed. This results
in e.g. Firefox navigating through the history instead of scrolling the
page when using the mouse wheel on it.
We don't get any information about modifiers while we are missing
keyboard focus, so assuming no modifiers are active is the best we can
do.
The shell sends us a modifier update immediately before we regain
keyboard focus, so the state shouldn't get out of sync.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2112
We're normally going from a fixed size to a floating state when we're
using the saved size, meaning we're practically always going towards a
state where the shadow margin will non-empty. However, if we don't
include any margin when creating a new configure request, we'll end up
resizing to a slightly smaller size as gtk will cut off the margin from
the configure request when changing the window widget size.
This wasn't visible when e.g. going from maximized to floating, as we'd
add the shadow margin at a later point, which would effectively "grow"
the widnow size, but when we're going from tiled to floating, we both
start and end with a non-empty shadow margin, meaning we'd shrink ever
so slightly every time going between tiled and floating.
We should never save a size when we're tiled, just as we shouldn't when
we're maximized. This fixes returning to the correct floating size after
having been tiled or maximized.
If a window is configured with a fixed size (it's tiled, maximized, or
fullscreen), ignore any resize call that doesn't respect this. The set
size will instead be saved, when appropriate, so that the new size is
used when e.g. unmaximizing.
This makes it possible to call 'gtk_window_resize()' while the window is
maximized, without the window actually changing size until it's
unmaximized. Changing size to a non-maximized size is a violation of the
xdg-shell protocol.
An application may want to set a fallback size of a window while still
mapping maximized. This is done by calling gtk_window_resize() before
gtk_window_maximize() and before gtk_window_show(). When the window is
mapped, it should have a maximized size, and if it eventually is
unmaximized, it should fall back to the size from the earlier
gtk_window_resize() call.
What happens before this commit is that the initial window size ends up
respecting the first gtk_window_resize() dimensions, and not the window
dimension configured by the Wayland display server (i.e. maximized
dimensions).
Fix this by postponing any configure events until we received our
configuration from the display server. If we got one with a fixed size
(e.g. we're maximized, tiled etc), we use that, otherwise we look at the
one that was previously configured by gtk which corresponds to the
"preferred" size when not being maximized.
This fixes Firefox being started in a maximized state when using the
Wayland backend.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2538
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: bb9c07d8fe8b90c42ba81fb5bb6f8a9826252660
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
