When enable-animations is false, the revealer's child-revealed property is
notified immediately, so make sure to connect to it before toggling the
revealer.
https://bugzilla.gnome.org/show_bug.cgi?id=719510
We rename the gtk_widget_class_bind_template_child{_internal}
macros by appending a _private to their name. Otherwise, it
would be too magic to pass the 'public' names as arguments,
but affect a member of the Private struct. At the same time,
Add two new macros with the old names,
gtk_widget_class_bind_template_child{_internal} that operate
on members of the instance struct.
The macros and functions are inconsistently named, and are not tied to
the "template" concept - to the point that it seems plausible to use
them without setting the template.
The new naming scheme is as follows:
gtk_widget_class_bind_template_child_full
gtk_widget_class_bind_template_callback_full
With the convenience macros:
gtk_widget_class_bind_template_child
gtk_widget_class_bind_template_child_internal
gtk_widget_class_bind_template_callback
https://bugzilla.gnome.org/show_bug.cgi?id=700898https://bugzilla.gnome.org/show_bug.cgi?id=700896
Using an offset from the struct means you can have children in
both the public and private (via G_PRIVATE_OFFSET) parts of the
instance. It also matches the new private macros nicer.
https://bugzilla.gnome.org/show_bug.cgi?id=702563
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
We've recently a number of classes wholly. For these cases,
move the headers and sources to gtk/deprecated/ and adjust
Makefiles and includes accordingly.
Affected classes:
GtkAction
GtkActionGroup
GtkActivatable
GtkIconFactory
GtkImageMenuItem
GtkRadioAction
GtkRecentAction
GtkStock
GtkToggleAction
GtkUIManager
A vertical action area causes the info bar to be imposingly large.
This defeats the whole point of the info bar which is to be
unobtrusive. Not to mention it is impossible to make it look
and feel good.
Commit cdf473ec10 deprecated the style
properties associated with the container border width and box spacing of
the action and content areas, in favour of using
gtk_container_set_border_width() and gtk_box_set_spacing() on the
widgets themselves, but failed to initialize those values to the
defaults.
The way we use these style properties to set regular properties on
containers accessible from the public API is really just broken, and
could lead to undefined values for the spacing and border-width
container properties (since they could be set from public API and then
changed from under in a style_update handler from GTK).
Take this as an occasion to deprecate these style properties, which do
not make a lot of sense anyway, now that GtkInfoBar supports regular CSS
padding and border.
InfoBar must take into account the border and padding when requesting
its allocation, since it is then drawing them. Besides, the border and
background should always be drawn, even when the message type is OTHER.
The message-type css classes must be in the widget context all the time,
not only when drawing, otherwise they are not propagated to the
children, for instance a label in the InfoBar must inherit the
color. Add a corresponding reftest.
https://bugzilla.gnome.org/show_bug.cgi?id=670555
All colors are defined now in the default css, and classes have
been added so the bars are fully themeable (as opposed to
gtk_widget_override_*, which require changing the color map itself)
The keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names.
Just one user in GTK+ continues to use gdkkeysyms-compat.h, which is
the gtkimcontextsimple.c, since porting that requires porting more
custom Perl code.
This commit was created using a script that searched for all docstrings
containing a parameter and the string 'or %NULL'.
Gdk backends and demos excluded as they are not part of a public API
https://bugzilla.gnome.org/show_bug.cgi?id=610474
