We require a C compiler supporting C99 now. The main purpose of
these fallbacks was for MSVC. From what I can see this is now all supported
by MSVC 2015+ anyway.
The only other change this includes is to replace isnanf() with the
(type infering) C99 isnan() macro, because MSVC doesn't provide isnanf().
It never makes sense to paint a texture that needs recoloring. If
you call the regular snapshot on a symbolic texture we just use the
default recoloring colors.
To support this we also change gtk_css_style_snapshot_icon_paintable()
to call gtk_icon_paintable_snapshot_with_colors() for IconPaintables
so that we get the correct colors, and we make it not emit the color
matrix.
Since we now rely on the icon to do the recoloring we also drop the
recolor argument in gtk_icon_paintable_snapshot_with_colors() as its
not needed anymore.
Previously, we wrapped all GtkCssShadowValues in a GtkCssShadowsValue,
even if it was just one shadow. This causes an unnecessary bloat in
css values.
Make each GtkCssShadowValue able to handle multiple shadows instead, and
use gtk_css_shadow_value* API everywhere.
The differenciation between a literal color value and an RGBA value
caused problems in various situations. Just treat the two the same but
don't allow access to the rgba value of a non-literal color value.
This gets rid of around 1.6k rgba values in the widget-factory.
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
Instead of making people intiialize a rectangle and then applying border
radius manually, provide a constructor that does it for them.
While doing that, also allow people to instead request the padding box
or the content box.
Refactor all relevant code to use this new constructor.
Grips have long been unused in GTK, so remove all support for them.
This removes the GTK_STYLE_CLASS_GRIP and the special
gtk_render_handle() code for drawing those grips.
The new function, gtk_render_background_get_clip answers the
question: what pixels are affected if I call gtk_render_background ?
The long-term goal is to have APIs that answer this question for
all rendering primitives.
In https://bugzilla.gnome.org/show_bug.cgi?id=601425 the annotations
were changed to int as they not only take the predefined enum values
but also user defined values registered through gtk_icon_size_register()
As a result the typelib doesn't contain any information about
GtkIconSize for those arguments and the Python docstring only
shows the corresponding Python type "int".
This changes the argument docs to mention the type explicitly
so the Python doc generator can add a link to Gtk.IconSize
which contains the most useful predefined values.
https://bugzilla.gnome.org/show_bug.cgi?id=757411
It is not necessary for the users of this API, and causes things
to not work as intended. Without this transient node, styling
"notebook header tabs arrow" has the desired effect on notebook
arrows.
A GdkPixbuf has no scaling factor, so drawing directly from it can only
using a scale of 1, to avoid blurry, fuzzy icons.
You should be using gtk_render_icon_surface() anyway.
