These are a family of pretty specialized widgets, and
are very rarely used. Instead of porting them away
from GtkTreeView and GtkComboBox, deprecate them.
Add a GtkColumnView scrolling performance test similar to the one used
previously in https://gitlab.gnome.org/GNOME/gtk/-/issues/3334.
The test creates a table with 20 columns and 10,000 rows and scrolls it
to a random position every frame, while measuring the frame times.
There is a commandline flag to pick the cell widget between none (for
benchmarking raw column view scrolling) and various label types. There
is also a commandline switch to disable automatic scrolling in case a
manual assessment is desired. Finally, there's an argument for
controlling the number of columns.
According to OpenGL spec, a shader object will only be flagged
for deletion unless it has been detached; when a program object
is deleted, those shader objects attached to it will be detached
but not deleted unless they have already been flagged for deletion.
So we shall detach a shader object before it is deleted, and delete
it before the program object is deleted best.
It was used by all surfaces to track 'is-mapped', but still part of the
GdkToplevelState, and is now replaced with a separate boolean in the
GdkSurface structure.
It also caused issues when a widget was unmapped, and due to that
unmapped a popover which hid its corresponding surface. When this
surface was hidden, it emitted a state change event, which would then go
back into GTK and queue a resize on popover widget, which would travel
back down to the widget that was originally unmapped, causing confusino
when doing future allocations.
To summarize, one should not hide widgets during allocation, and to
avoid this, make this new is-mapped boolean asynchronous when hiding a
surface, meaning the notification event for the changed mapped state
will be emitted in an idle callback. This avoids the above described
reentry issue.
GtkTreeView.get_tooltip_context() takes an inout X and Y coordinates,
but the "out" side is a side effect: the conversion from widget-relative
to bin window-relative coordinates is not documented, and can be done
using public API, if needed.
GtkIconView.get_tooltip_context() follows the same pattern, and takes
two inout arguments for the coordinates, but it does not change them any
more, after GtkIconView's bin window was dropped in commit 8dc5e13e.
There's really no point in having these `inout` arguments, and while
GtkTreeView and GtkIconView are certainly de-emphasised in GTK4, and we
nudge developers to move to the new list views, we should take advantage
of the API break to remove warts.
Using GtkCssSection in public headers here may be
ok from the C perspective, since it all ends up in
the same library anyway. But it causes circular
dependency problems for our gir files that are still
split by namespace.
To avoid this problem, copy the GtkCssLocation struct
struct as GskParseLocation, and pass take two of them
instead of a GtkCssSection in the error callback.
Update all users.
Fixes: #2454
Copy the format conversion code from GdkMemoryTexture
so we can produce all formats, and test them all.
The upload fast paths assume that the stride is a
multiple of four, so some of the padding values cause
it to fail. Apart from that, things seem to work for
all combinations.
Create textures with various characteristics (alpha, premultiplication,
stride) that trigger different code paths in the gl texture upload
function, and show the resulting images. If all goes well, they all
should look the same.
On my system, this tests texture upload for memory formats
GDK_MEMORY_B8G8R8A8_PREMULTIPLIED, GDK_MEMORY_R8G8B8A8, and
GDK_MEMORY_R8G8B8, and it works with both gl and gles.
Drop gtk_column_view_column_new_with_factory and
just make gtk_column_view_column_new accept a
nullable factory. This follows what we've been
doing elsewhere.
Update all callers.
