This call is not necessary, because gtk_css_node_set_parent() does the
right thing. (It probably hasn't been necessary for years, but I'm
not gonna try my luck on GTK3 at this stage.)
This code is usually called the first time
gtk_widget_get_style_context() is called on a widget and its style
context gets create. At that point however, the css nodes are in the
right place already, so no invalidation should happen.
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.
Signal names must start with a letter. They can’t start with a hyphen.
It was originally added in commit 74f4c6f6bd with no given reason
for why the signal name was chosen as it was.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If we set c_marshaller manually, then g_signal_newv() will not setup a
va_marshaller for us. However, if we provide c_marshaller as NULL, it will
setup both the c_marshaller (to g_cclosure_marshal_VOID__VOID) and
va_marshaller (to g_cclosure_marshal_VOID__VOIDv) for us.
When the widget gets finalized it clears the widgetnode and gtk_css_widget_node_get_widget
returns NULL. Guard against gtk_css_widget_node_get_widget() returning NULL like in other
places.
See https://gitlab.gnome.org/GNOME/pygobject/issues/28#note_82862
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.
Insist that a first non-NULL property is passed to
gtk_style_context_get().
This is in particular relevant because of dropping the state argument
since GTK3, and code like
gtk_style_context_get (context, state, "font", &font);
would keep compiling without warnings without this change.
This is just lots of renaming.
The interface remains private, so the public API does not change, apart
from removing the definition of the Interface object to avoid
subclassing.
The language is useful for parsing tools, such as that of gtkmm, which
otherwise assumes these are C snippets and elides them from its
generated documentation.
So we can avoid creating a GtkCssPathNode in _init and then throwing it
away right after when using the _new_with_node constructor, which is the
one we use for all widgets.
It wasn’t clear that gtk_style_context_get[_valist]() behave like
g_object_get() — i.e. pointer-based types are returned newly-allocated.
Clarify that.
https://bugzilla.gnome.org/show_bug.cgi?id=773954
