This is an unused feature that's way too complicated for a default
calendar widget and complicates the implementation a lot. Since we want
to eventually replace this with actual widgets, remove the details
support now.
Instead, rely on people passing fallbacks explicitly.
Alternatively, GThemedIcon provides the functionality to create
fallbacks, which is what GtkImage and the testsuite now use.
That method is slightly better, too, so the expected test results
have been updated accordingly.
There is no way to query contexts or do anything useful with them.
So don't keep track of them and don't make them an argument in public
APIs with the docs saying "I don't know what to use here, maybe read
some spec somewhere".
Those functions are unused and the documentation says "Returns some
random number that the icon theme creator chose" which does not seem at
all useful and an implementation detail.
So get rid of it.
Most users were just forgetting to set the proper flags.
And flags aren't the right way to set this anyway, it was just
acceptable as a workaround during GTK3 to not break API.
The API encouraged wrong usage - most of the users were indeed wrong.
Use the correct version instead:
gtk_icon_theme_get_for_display (gtk_widget_get_display ())
We only have implementations of this on X11 and Win32,
so make it available as backend api there.
Update all callers to use either the backend api, or
just monitor 0.
This is an attempt to see how we can use sysprof data
in our tests to extract useful performance numbers.
Use it as a wrapper around any GTK+ process:
./testperf ./gtk4-widget-factory
Currently, it repeatedly runs the given commandline,
extracts the first css validation time from the resulting
syscap file, and prints out the min/max/avg of the runs
at the end.
This relies on the environment variable GTK_DEBUG_AUTO_QUIT
to cause the process to exit soon after launch.
Remove arguments from the constructor.
For actions, we now default to COPY, which is the most common one
that we should enable by default (MOVE requires handling deletion
on the the source side, and ASK only makes sense if we have
multiple actions).
For the content provider, we add a new ::prepare signal where
it should be provided just-in-time.
