[NSView frame] returns a rectangle in the superview's coordinates, and the
superview of an NSWindow's content view (which is the only NSView that
GdkQuartz instantiates) is an undocumented NSThemeFrame. While it happens
to have the same origin as the content view and the same size as the
window's frame this isn't documented and so could change without notice.
Convert the window frame coordinates to the view's coordinate system to
ensure consistency.
Use the view's bounds instead of its frame: The bounds rectangle is in the
view's coordinate system. Use the parent NSWindow's frame instead of the
private NSThemeFrame's. This ensures that all coordinate comparisons have
the same reference.
Finally, the macOS coordinate systems origin is at the bottom left, so the
title bar is between the content view's height and the window's height,
not in negative y in the view's coordinates. Adjust the y comparisons
accordingly.
Fixes#6297
gtk_widget_translate_coordinates() uses int argument and thus cuts off
any decimal parts. This can leads to reduces accuracy when e.g.
measuring the distance of a drag.
GTK4 is not affected as the translations is done differently.
Our webdav server has a root which is davs://mynextcloud/remote.php/webdav
When once creates a GFile out of or out of a subdirectory, and one call
g_file_get_parent(), it recurses too far up and try to query
davs://mynextcloud/remote.php which fails, resulting in a broken pathbar.
To fix that, before querying the metadata of each element of the path,
I query the "enclosing mount", then use it's root to compare the GFile
against.
This is a backport of !5830 to 3.24
On X11, gdk_window_move_to_rect() uses the position of the window to
calculate how it should be moved. However, any pending resizes that will
be executed on show() are not taken into account, resulting in
incorrectly positioned tooltips in case a tooltip window is re-used
often. This is not solved by gtk_widget_realize(), as this will do
nothing if the window is already realized.
Let's add a call to the private gtk_window_move_resize() function, so
that the size is always recalculated before the window is sent to
gdk_window_move_to_rect().
This exact fix was also needed in GtkMenu (7298e73c), with similar
reasoning.
Fixes#2142Fixes#2227
On Windows with certain keyboard layout combinations you can get a
benign terminal warning like this:
Could not open registry key 'SYSTEM\CurrentControlSet\Control\Keyboard
Layouts\D0010413'
When using a lot of plug-ins, like GIMP does, this warning can show up
a lot of times.
The code after this warning, still has another last check, that, when it
fails, will show a warning.
We change the first g_warning to a g_debug statement, to reduce the
amount of warning messages.
Closes#5109
This fixes potential runtime crashes in some somewhat unlikely
configurations, like a modern compositor but gtk built against an old
wayland protocols version.
We only need v2 for the tiling fixes, so request that.
On GTK3 the msys2-mingw64-meson job is failing due to error:
mingw-w64-x86_64-pkg-config and mingw-w64-x86_64-pkgconf are in
conflict. Remove mingw-w64-x86_64-pkgconf? [Y/n]
To fix this we change required package pkg-config to pkgconf, which
is what the GTK4 branch also uses.
cairo_image_surface_get_width() and cairo_image_surface_get_height()
return the image size that's in the device pixels.
On the other hand, _gdk_wayland_display_create_shm_surface() takes a
surface size in the logical pixels.
Given that _gdk_wayland_display_get_cursor_for_surface() provides the
desired surface size in device pixels, a much bigger shm surface is
created, which then breaks damage tracking code in
gdk_wayland_device_update_window_cursor().
Fixes#6242
And get the embedder before continuing, as the backend-specific
get_monitor_at_window () only knows about its own windows.
In order to check for offscreen windows, we introduce a new function
gdk_window_is_impl_offscreen (). Unlike gdk_window_is_offscreen (),
it doesn't rely on the window_type field, but actually checks whether
GDK_WINDOW_IMPL_GET_CLASS (window->impl) is GdkOffscreenWindow.
See previous commit for informations.
Checking for offscreen windows with gdk_window_is_offscreen ()
is not enough in this case. What we want here is that the impl
classes match, as backends are meant to know only about their
windows. Instead gdk_window_is_offscreen () checks whether the
GdkWindow.window_type field is GDK_WINDOW_OFFSCREEN.
In the case of child windows in offscreen windows, the window
type is GDK_WINDOW_CHILD, even though their impl is still
GdkOffscreenWindow.
So actually check whether GDK_WINDOW_IMPL_GET_CLASS (window)
matches GDK_WINDOW_IMPL_GET_CLASS (parent).
We may also consider getting the toplevels from child windows,
as transient-for relationships are really about toplevels, but
child windows doesn't seem to cause problems in practice.
This was basically done copying the gtk4 version and keeping the changes
that weren't gtk4 specific.
Fixes#6224 (the chooser doesn't close but we don't crash or such)
The Adwaita cursor theme is moving to shipping just standard cursor
names, so we should fall back to 'default' instead of 'left_ptr' if
a named cursor can't be found.
Fixes: #6259
