Similar to previous removals of g_cclosure_marshal_VOID__VOID we can remove
other marshallers for which are a simple G_TYPE_NONE with single parameter.
In those cases, GLib will setup both a c_marshaller and va_marshaller for
us. Before this commit, we would not get a va_marshaller because the
c_marshaller is set.
Related to GNOME/Initiatives#10
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.
They're either wrong (when using FALSE because the widgets don't account
for changes to the CSS) or unnecessary (when using TRUE because it's the
default).
Fixes!1777
Surface returned from gtk_icon_helper_load_surface can be smaller
then requested pixel size. This happens when icon is embedded in
panel that has bigger size then loaded pixbuf.
Fixes#1280, tray icons not drawing background. This is a magic pattern only
usable for gdk_window_set_background_pattern() that sets the underlying
X window's background to ParentRelative.
A user in #gtk+ was confused what to do instead of creating a Button via
gtk_button_new_from_stock(). Our docs could stand to be clearer on this
point; it only costs a few lines. So, link from that constructor* to the
GtkStock doc, and add a banner there telling folk they shouldn’t use it.
* not that most [of these][links] even work right now…
We link to the HowDoI for GNotification in the class description, but we
should be more verbose in the deprecation notices for each function of
the GtkStatusIcon class.
https://bugzilla.gnome.org/show_bug.cgi?id=743975
It tried to set the expand state if either xexpand/yexpand where true.
Due to a missing queue_compute_expand when adding a child it actually
only computed the expand state in case a child queued after being added
or in case a child had the expand property set (see optimization in
gtk_widget_set_parent)
In my case this broke layouts as a child of GtkCombBox started setting
an exand flag with 3.20 which queued a compute_expand, which in turn
propagated an expand child props set for a cell in the same table up
and overrode the expand child prop of a parent GtkBox.
This removes the custom compute_expand implementation to match the
behaviour of GtkBox (don't propagate child prop expand flags
but let child expand flags override the child props) and not get random
expand behaviour depending on whether and when child widgets set their
expand state.
https://bugzilla.gnome.org/show_bug.cgi?id=769162
We're seeing loops where the size of some status icons constantly
dithers between 24 and 25. Since I couldn't track down exactly
where the one extra pixel comes from, just stop reacting
to single-pixel size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=758893
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
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
