The main corpus of the documentation for gtk_window_get_size() is still
full of X11-isms, so we should port it to something that is more
backend-agnostic. Additionally, having some examples would be nice for
application authors looking at a way to appropriately use this function.
If somebody decides to use gtk_widget_set_double_buffered() in the
middle of a draw() then there's the risk of calling end_draw_frame()
with an invalid pointer.
Some overeager compilers may warn about the double_buffered bit field
changing values and leading to a potentially uninitialized variable.
In order to avoid compiler warnings or crashes, we can simply store the
value of the double_buffered bit field at the beginning of the rendering
and use that instead of the actual bit field.
https://bugzilla.gnome.org/show_bug.cgi?id=771463
Not all occurrences of this warning can be fixed today, so put it behind
a G_ENABLE_DEBUG flag since it still shows legitimate problems even if
some of them are false positives.
A popup may have moved and resized when configured. Make sure every
layer knows about this and call gdk_window_move_resize() with the
configured dimension and position. This won't actually move the
window, but might resize it.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
The result of move_to_rect, received from the xdg_popup.configure
event, needs to be translated to the correct coordinate space; that is
from real parent window geometry to coordinates relative to the gdk
window set as transient-for.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
Use a helper to translate a coordinate from non-real GdkWindow parent
to window geometry coordinate space of the real GdkWindow parent,
meaning the coordinate space of the GdkWindow of the parent used as a
xdg_popup parent where (0, 0) is inside of the shadow margin.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
When using the dynamic positioner (i.e. positioning from move_to_rect)
we can always rely on having a proper transient-for to position
relative to, so lets drop the ignored parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
Move the code used for calculating the result of move_to_rect
(final_rect, flipped_rect etc) closer to the other move_to_rect
functions (i.e. next to create_dynamic_positioner), and let the
xdg_popup configure handler just call the calculation function.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
If an application umaps the toplevel from its popup callback, this can
lead to a protocol error.
Make sure we mark popup parent and use that to check if their parent is
the toplevel being unmapped in which case we shall unmap the popup first
to avoid the protocol error.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=770906
The fix for bug 767468 had some unintended side-effects. This is
an attempt at doing the same fix (don't grab focus when we are
grab-shadowed), while avoiding the breakage, by using GTK+'s
internal tracking for grab-shadowed-ness.
https://bugzilla.gnome.org/show_bug.cgi?id=770508
Analogous to (un)mount operation, we now keep a reference around
during the ongoing operation and make use of the destroyed flag
to check if we are still alive or if we have been cancelled as
a result of the widget being destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=764979
Since we hold on to a reference during (un)mount operations, we
don't trigger the cancellation of operations in finalize anymore.
Instead we now override the GtkWidget's destroy() and cancel any
ongoing operations there.
https://bugzilla.gnome.org/show_bug.cgi?id=764979
The current code wrongly assumes that cancellation can only happen
as a result widget finalization, and consequentially does not
properly recover from it. Therefore if the operation is cancelled
as a result of user interaction, the entry is will stay disabled
and the spinner will keep spinning. This is fixed by removal of
the early bail out in case of cancellation.
https://bugzilla.gnome.org/show_bug.cgi?id=764979
