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>
Many parts of GTK+ assume that all windows have a cairo surface
assoicated with them. This change provides a logically 1x1 cairo surface
(respecting scale) for the root window.
https://bugzilla.gnome.org/show_bug.cgi?id=704554
Setting up the icon and desktop file is a pretty central part
of making an application work, so we should do it for our example.
The fact that the examples are uninstalled makes this a little
more complicated.
I disconnected signals in dispose() to avoid a visible-tab
change notification during destruction, but this is clunky.
Instead, make the notify::visible-tab signal handler bail out
early when called during destruction.
This value is highly sensitive to changes in the theme; we
don't want to have to tweak hardcoded integers in this test case
every time we rev gnome-themes-standard.
Future iterations could do more heuristic matching, but this
is enough for now.
https://bugzilla.gnome.org/show_bug.cgi?id=704747
Plug windows weren't redrawing properly because the embedded
window was expecting to get messages for each frame from the
compositor, but the compositor doesn't know about embedded
windows. Simply disable frame sync for GtkPlug's GdkWindow -
extending XEMBED to handle frame sync isn't interesting
at this point.
A new API gdk_x11_window_set_frame_sync_enabled() is added
to allow this to be done.
https://bugzilla.gnome.org/show_bug.cgi?id=701613
Add introspection friendly version of gtk_tree_model_rows_reordered
with a "_with_length" suffix. This allows language bindings to
safely pass an array with length argument. Use the "Rename to:"
annotation to expose as "gtk_tree_model_rows_reordered".
https://bugzilla.gnome.org/show_bug.cgi?id=684558
Add a new example to the getting started part of the docs. The focus
of this example is on 'new stuff': GtkApplication, templates, settings,
gmenu, gaction, GtkStack, GtkHeaderBar, GtkSearchBar, GtkRevealer,
GtkListBox, GtkMenuButton, etc.
It is being developed in several steps. Each step is put in a separate
directory below examples/: application1, ..., application8. This is a
little repetitive, but lets us use the code of all examples in the
documentation.
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
Declare variables at the top to the block.
G_GNUC_BEGIN_IGNORE_DEPRECATIONS and G_GNUC_END_IGNORE_DEPRECATIONS with
a ';' at the end is still considered a statement, even if these macros
expand to nothing, which C89 compilers don't really like (oddly speaking)-
but this is life.
