In order to make the cairo renderer/context behave more similar to how
the OpenGL and Vulkan renderer/context behaves, request a frame callback
and commit in the end frame vfunc.
This means the end frame vfunc in cairo does
* attach buffer
* request frame callback
* sync surface state
* commit
Where as e.g. the OpenGL version of the same flow does
* attach buffer
* request frame callback
* sync surface state
* eglSwapBuffers()
where eglSwapBuffers() indirectly calls wl_surface_commit().
When we remove anchors with widgets from the text
buffer, we used to call gtk_widget_destroy(), which
indirectly called gtk_container_remove() which cleared
the child properly. When gtk_widget_destroy() was
removed, we replaced the calls with gtk_widget_unparent(),
but that is not enough. Explicitly call
gtk_text_view_remove() instead - we know the parent
is a text view.
Since the changes to GDK to use surface subtypes, CSD windows were
broken because we did not set the window styles properly. Fix this by
first acquiring whether decorations are used by the GtkWindow, and based
on that result we set the decorations that we want to use accordingly
and so apply them.
Thanks to Matt Jakeman for investigating into the issue and providing
pointers to a proposed fix.
Fixes issue #3157, besides the part where window sizes are not correct
since that is likely caused a separate issue.
Quickly clicking rows should always activate the row if
single-click-activation is enabled. Before, only the first click
(n_press == 1) would activate the row.
Using gtk_widget_insert_before on a complex container
is a *bad* idea; it will mess up the containers bookkeeping
of its children and can easily lead to failure and crashes.
While it's a bit dubious whether array+length annotations should be
marked as "nullable", we do this elsewhere in the API, so might as well
be consistent.
In practice, the array argument is only ever allowed to be NULL iff the
length argument is 0; annotations are static, so if somebody decides to
pass a NULL argument with a non-zero value, they will get a run time
critical error, instead of a compile time one, which is somewhat counter
to the point of annotating the API in the first place.
Fixes: #2923
When claiming a sequence in a gesture signal handler,
the expected result is that GtkGesture::handle-event
returns TRUE, causing the event to not be propagated
further.
This doesn't work for button release events, since
gtk_gesture_handle_event does the following:
add point
emit ::update
remove point
check claimed status
The ::update signal is where the application code
claims the sequence. But removing the point purges
the sequence from the gestures memory, so checking
the claimed status returns FALSE.
This patch fixes things to behave as expected, by
checking the claimed status before removing the point.
