Accessors like these are weird to have and we can add widgets to the
content area via gtk_container_add() as well as add widgets to the
action area via gtk_info_bar_add_action_widget().
The function is fundamentally broken for unbounded surfaces.
If a surface is unbounded, we cannot represent this as a
cairo_rectangle_int_t, and using the return value doesn't work because
it's already used for something else.
In GTK3, unbounded surfaces aren't a problem, but GTK4 uses recording
surfaces.
So better remove that function before we keep using it and using it
wrong.
It is not great to put a function in the public api and
document it as "do not call this" only so we can refer
to its docs in other places. Therefore, fold the docs
directly into the input handling overview chapter.
These are always set to the same value as the corresponding border
radius properties. They are also non-standard, so remove them and
replace them with the border radius properties everywhere.
Fixes#2414
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.
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.
We expose no API to get at any colors for drawing symbolics, so we
shouldn't have APIs to draw with them.
Apart from that, those APIs look like a box of crayons, not like an
icontheme.
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 ())
This is a useful widget to have, and it has minimal api.
Not having it public forces apps to recreate a lot of
complicated machinery for not good reason, if they need
an Emoji chooser in a different context.
We rely on a specific minimum version of gtk-doc to be able to build the
GTK API reference for the new API. In order to be able to use gtk-doc as
a subproject, though, we need to use a recent version of Meson.
Add GtkWidget API for adding and removing style classes, as well as
checking whether a widget has a style class applied.
Everyone has to go through GtkStyleContext for this these days but with
GtkStyleContext eventually going away, it makse sense for GtkWidget to
have API for this.
