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.
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
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.
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
This reverts commit 6d545b6d03.
Reverting as this broke multi DPI systems, where a client is expected to
render at scale = 1 if it is only visible on a scale = 1 monitor.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2129
The xdg_output.done event is deprecated in xdg-output v3, so clients
need to rely on the wl_output.done event instead.
However, applying the changes on the fist wl_output.event when using
xdg-output v3 may lead to an incomplete change, as following xdg-output
updates may follow.
Make sure we apply xdg-output events on wl_output.done events with
xdg-output v3.
https://gitlab.gnome.org/GNOME/gtk/issues/2128
I was not getting any gtk+ profile markers output from the frame clock
when I was profiling an OpenGL app (gnome-hexgl). I debugged this and
it turns out that the profiling depends on getting the _NET_WM_FRAME_TIMINGS
event from the compositor, and once we switched to OpenGL rendering
this never appeared.
It turns out the reason it didn't is that the compositor only does
so if the client increases the counter tied to the window, and the
x11 gdk code has this optimization where if we do a draw pass
but nothing is actually drawn we don't update the counter.
Unfortunately the detection of whether something was draw or not
is based on some cairo surface hack that breaks when we render with
OpenGL instead. The fix is to just always update the counter if
we're drawing with OpenGL.
This was added with https://bugzilla.gnome.org/show_bug.cgi?id=148032
to make gtk compile against X11R5, see commit 3b9a31df0
That release is >20 years old now, so we can safely remove it.
The motivation for this is to remove any checks that we don't have in the
meson build.
This fixes an issue where stylus proximity in/out events emulate enter/leave events.
The emulated events didn't contain the correct slave device and therefore the
resulting device class was set incorrectly. Crossing event emulation now also
works with slave devices.
Closes#2070Fixes#2070
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2070
We clamp to 32767 when creating a new X11 GdkWindow due to larger sizes
not being supported, but still try to resize to larger when
gdk_window_resize() is called. Fix this by clamping in both places.
This fixes an issue in mutter where ridiculously sized Java windows
would not show up.
The current code only goes through the output associated to the
window's wayland surface enter/leave events. That means that to update
the scale factor the window only looks at the outputs on which it
received enter/leave events. That doesn't include a new monitor
connected to the system on which the window might be display next.
The spirit of the existing logic seems to be to go through all the
scale factor available on the current monitors of the system and pick
the highest. So fix the current behavior by looking at the monitor on
the display.
Fixes#1144.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
