We must wl_surface.commit after xdg_surface.ack_configure to make it
have an effect. We failed to do so when a configure event didn't result
in new updates, so make sure we fall back on an simple
wl_surface.commit if there was no new actual frame painted.
Closes: #2910
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
