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
Because otherwise when the file list is sorted "by name"
and the new name causes the file to be re-sorted to another
row, the selection stays in the old row which is now
occupied by a different file.
Fixed by keeping track of the renamed file and revealing
it in the "row-changed" signal handler, which gets emitted
after a file is renamed.
Fixes issue #948
When loading a SVG icon from a gresource file only containing SVG icons,
but without having a SVG loader available in gdk-pixbuf, we would crash
when trying to eventually load the resource. Fix this by gracefully
handling this by simply failing to load the icon, while the first time
it happens, log a warning.
https://gitlab.gnome.org/GNOME/gtk/issues/2084
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>
When explorer.exe creates a taskbar it broadcasts a "TaskbarCreated"
message to all toplevels. Applications, By handling that message,
are able to re-create the icons to be displayed in the taskbar.
Explorer creates a new taskbar in two circumstances:
A) when explorer starts up
B) when the DPI of the monitor changes
A) happens either when explorer.exe is started for the first time at
logon, or when it is restarted after being terminated.
B) happens when the user changes the DPI preference of the active
monitor where the desktop is displayed, or if the desktop is moved
to a monitor with different DPI.
Currently, this message is handled in Gtk and icons are re-created.
However the current implementation has a small issue in that it
doesn't set the tooltip on the new icons, so tooltips get lost
after re-creation.
The tooltip is important because Windows uses it for identification
of taskbar icons and for storing and applying user preferences. For
an explanation of that see:
https://bugzilla.gnome.org/show_bug.cgi?id=609622
With this commit the tooltip is correctly applied to new taskbar
icons when handling taskbar_created_msg.
See Merge Request !1003
