We can't destroy buffers if they're in-use by the compositor. Well,
technically we can, but that is considered undefined by Wayland and
mutter won't cope with it very well -- it simply kills the client.
To solve this, we need to delay the destroy operation until the
compositor tells us that it's released the buffer. To do this, hold
an extra ref on the cairo surface as long as the surface is in-use
by the compositor.
This prevents warnings like
(gtk3-demo:14948): Gdk-CRITICAL **: _gdk_frame_clock_thaw: assertion 'GDK_IS_FRAME_CLOCK (clock)' failed
(gtk3-demo:14948): Gdk-CRITICAL **: gdk_frame_clock_get_timings: assertion 'GDK_IS_FRAME_CLOCK (frame_clock)' failed
We need to do this, as the compositor might have already sent us a frame
event, in-flight, at the same time we destroy our window. In this case, we'll
receive the then-in-flight "done" event, and then warn as we try to look
up the frame clock on a destroyed window.
Put dialogs and utility windows in the same level as normal and
toolbar windows so that Gtk can control their stacking instead of
forcing them, rather unnaturally, to be on top of all other windows,
even other application windows, even when another application has
focus.
This setting will let us keep traditional appearance
of dialogs on platforms where this is expected.
The new setting is called gtk-dialogs-use-header, backed
by the Gtk/DialogsUseHeader xsetting.
The EWMH defines _NET_WM_MOVERESIZE_SIZE_KEYBOARD and
_NET_WM_MOVERESIZE_MOVE_KEYBOARD for operations that are not
initiated by a button-press event. Allow using these by passing
a button of 0 to gdk_window_begin_move/resize_drag.
fvwm seems to have problems keeping _NET_WORKAREA in sync with
the number of desktops. Instead of reading garbage, silently use
the full screen as workarea for desktops that are not covered
by the _NET_WORKAREA property.
https://bugzilla.gnome.org/show_bug.cgi?id=698248
Applications need a way to fix or adapt the decoration layout,
for situations like split header bars. Setting the layout from
the theme with a style property did not offer a good way to do
this, and the ::show-close-button property does not provide
fine-grained control.
To improve the situation, move the layout string to a property of
GtkHeaderBar which is backed by a setting. This allows platforms to
set a default button layout independent of the theme, while applications
can override the default.
The style GtkWindow style property is now deprecated and ignored.
Since update_windows list is a static variable in GdkWindow.c which
contains pointers to windows which needs to be updated, it can happen
that it contains a pointer to a window even after quit from a gtk_main().
If another gtk_main() is called in the same process it tries to process
windows in the list which leads to a crash.
Correct reference count handling of added windows prevents such applications
from crash.
https://bugzilla.gnome.org/show_bug.cgi?id=711552
And deprecate the X11-specific version of it.
We call this new API _set_shadow_width() and not _set_frame_extents()
because we already have a gdk_window_get_frame_extents() with a
different meaning and different type of value.
https://bugzilla.gnome.org/show_bug.cgi?id=720374
The focus handling code is shared between core and XI2 implementations,
so just handle the extra XI2 types for passive grabs. Those must be dealt
with in the same way than active grabs. Focus events with this crossing
mode could happen currently through the XIGrabFocusIn passive grab.
https://bugzilla.gnome.org/show_bug.cgi?id=719762
This fixes potential assertions if a GTK+ app gets to receive
a XINotifyPassiveGrab/Ungrab pointer crossing event, currently
triggerable by XIGrabEnter passive grabs.
http://bugzilla.gnome.org/show_bug.cgi?id=719762
This is so we always have the latest information given by XRandR (or other), and not
rely on Core protocol information that might not have been updated yet.
This is specially visible when a monitor is connected (less frequent) or disconnected
(much more frequent), callbacks on GdkScreen::monitors-changed that call
gdk_screen_get_width/height() could get the screen size previous to the monitor
rearrangement.
So in order to fix this, keep track of the latest monitors information, and calculate
the bounding box in order to know the screen size.
https://bugzilla.gnome.org/show_bug.cgi?id=715029
Scroll valuators were being just appended again and again, leading
to 1) a growing memory issue anytime a device changed 2) the first
scroll valuators to stay permanent on the application lifetime, as
the first stored valuators would always match.
https://bugzilla.gnome.org/show_bug.cgi?id=705203
Passive grabs may take pointer focus out of the application, even though
the pointer didn't leave the window, but those events still trigger resetting
of the scroll axes. This is most visible with compiz, and possibly other
reparenting WMs, where passive grabs happen on the WM-managed window that
is a parent of the application toplevel.
As it is not possible to have scrolling happening on the timespan a passive
grab takes action, it is entirely safe for GTK+ to assume none happened if
it gets a crossing event of that nature.
https://bugzilla.gnome.org/show_bug.cgi?id=699574#c33
